Java Buzz Forum - A classical Finalizer problem in Netbeans 6.1

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Java Buzz Forum
A classical Finalizer problem in Netbeans 6.1

0 replies on 1 page.

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 0 replies on 1 page

Markus Kohler

Posts: 74
Nickname: kohlerm
Registered: Jun, 2008

Markus Kohler is an software architect at SAP

A classical Finalizer problem in Netbeans 6.1

Posted: Jun 20, 2008 7:28 AM

This post originated from an RSS feed registered with Java Buzz by Markus Kohler.
Original Post: A classical Finalizer problem in Netbeans 6.1 Feed Title: Java Performance blog Feed URL: http://feeds.feedburner.com/JavaPerformanceBlog Feed Description: My blogs about Java Performance related topics	Latest Java Buzz Posts Latest Java Buzz Posts by Markus Kohler Latest Posts From Java Performance blog

Recently I tried the Netbeans UML module to sketch some simple use case diagrams.
It worked pretty well, but it didn't feel very responsive all the time. I quickly checked the memory consumption and found that it would be much higher than during my last test.

I therefore took another heap dump. Here comes the overview:

Finalizers?

So times time Netbeans needed 74,2 Mbyte much more than last time
Surprisingly 15,5Mbyte alone are consumed by instances of the class java.lang.ref.Finalizer.
Such a high memory usage caused by Finalizer instances is not normal.
Usually you would see Finalizer instance using a few hundred Kbyte.
Next I simply checked the retained set (the object that would be reclaimed, if I could remove the Finalizer instances from memory) of these Finalizer instances:

So int[] arrays are consuming most of the memory. I again used the "immediate dominator" query on those int[] arrays to see who is keeping them in memory:

So lets take a look at those sun.awt.image.IntegerInterleavedRaster instances and see who is referencing them:

Can we blame Tom Sawyer?

We see again that java.awt.image.BufferedImage is involved as well as Java2d.
surfaceData sun.java2d.SunGraphics2D is referenced by com.tomsawyer.editor.graphics.TSEDefaultGraphics (what a nice package name).
Lets look at the code of surfaceData sun.java2d.SunGraphics2D:
public void dispose()
{
surfaceData = NullSurfaceData.theInstance;
invalidatePipe();
}

public void finalize()
{
}

"dispose" should clean surfaceData, but at least to to me it seems that nobody has called it.
So I decompiled TSEDefaultGraphics and found dispose to be empty:

public void dispose()
{
}

So my guess is (without digging deeply into the code) that TSEDefaultGraphics needs to be fixed and call dispose on it's surfaceData instance variable.

At the End

What this shows, is that you not only need to be very careful with implementing finalize(), but yo also need to take check whether you use objects that implement finalize().
Objects that really need to implement finalize should be small and you should not reference large objects.

Read: A classical Finalizer problem in Netbeans 6.1

Previous Topic

Next Topic


	Web Artima.com