Skip to main content

Removing JInternalFrames from the Heap

3 replies [Last post]
psilberk
Offline
Joined: 2006-08-02
Points: 0

Hello: I'm running a performance test opening and closing JInternalFrames in an application we are developing. Monitoring de Heap we realize after a while that the tenured generation starts to grow, slowly but permanently, even though it shows that the FullGC runs periodically. We suspect that the internal frames that should be removed from the Heap aren't removed.

The superclass of our InternalFrames is closing them with the setClosed method like this:

public final void cerrar() {
Logging.getLoggerTraza().info("Cerrando formulario : " + this.getClass());
predestroy();
try {
this.setClosed(true);
} catch (PropertyVetoException ex) {
Logging.getLoggerTraza().fatal("PropertyVetoException:Formulario.Cerrar");
}
}

We try it with the method remove of the Frame but didn't improve de results.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
bchristi
Offline
Joined: 2005-11-15
Points: 0

I profiled a small test case and could not detect any leaks from creating and closing JInternalFrames on 5.0 or 6.0b90. The only such problem I'm aware of was pre-5.0: bug 4836639.

Can you provide more information about your setup? Platform/O.S., JDK version, LookAndFeel, etc? Roughly how many JInternalFrames, and how much heap increase are we talking, here?

If you can post a small test case that reproduces the problem, I can have another look. Otherwise, I would recommend running with a profiler (the NetBeans profiler at http://profiler.netbeans.org/ is free) to see what you can find out.

-Brent

psilberk
Offline
Joined: 2006-08-02
Points: 0

The platform is Win95, but running the same test case in Win2000 shows the same behaviour a little less abrupt, in Win95 takes an hour to throw an OutOfMemory and in Win2000 two hours.
The reason to use Win95 is that we have a legacy application, with a lot of architectural functions that were written in a way that can only run under this platform.
These PCs (client) has 256mb of ram memory, and our new application has to share this memory with: word, excel, iexlorer and the old legacy application, so we have 70 - 90 mb of total memory in which our applicaction has to fit.
The jdk version is 1.5.0 but we made the same tests with 1.4.2 and there weren't significant changes.
The look and feel is com.jgoodies.plaf.plastic.Plastic3DLookAndFeel.
Is there any chance that our Object Retention is due to the look and feel?

bchristi
Offline
Joined: 2005-11-15
Points: 0

An OutOfMemoryError can be thrown when the system runs out of available HWNDs (see JDK bug 5088782). Win95 allowed far fewer HWNDS than later Windows versions, which could explain why Win2k takes longer to fail. Do you get a stack trace along with the OutOfMemoryError? If the app is able to run longer when you're not also running Word, Excel, et al, that could indicate that limited HWNDs are part or your problem.

Admittedly, it would be pretty strange to have the HWND problem with JInternalFrames, as HWNDs are created for heavyweight components and JInternalFrames are lightweight, but you should check this out to be sure.

It is definitely possible that the LookAndFeel could be involved with Object retention. The problem in 4836639 boiled down to a problem in the Windows and Motif LookAndFeels. This should show up in the profile, with references leading back to Plastic classes, or being Plastic objects themselves. Does the problem persist when using a different LookAndFeel?