Problem of memory liberation on an application Java (GUI swing) under Windows 2000 with the jre 1.4.

[Florent Coué]

Hello,

I have an application Java who is bounded to 64Mb.
This application instanciate a certain numbers of objects to attain about
30Mb a
thrown time.
On some actions, the application instanciate again the same objects.
The used memory increases in consequence.
First objects are not more referenced.
Normally, for all objects not referenced, the memory ought to be recoverred
by the garbage collector.
The memory ought to maintain to about 30 Mb.
But, It's not the case.
By forcing the garbage collector by System gc() or System
runFinalization() and tracing methods finalize() called on some objects, I
see that methods finalize() are not systematically called to recover the
memory.
To the end of a moment, the screens (swing) becomes of more slow as far as
to block
definitely.
Is it advised to make calls to System.gc() ?
Do you know the working of the garbage collector under Windows 2000 ?
Is it executed in a thread ?
How to avoid this kind of problem ?

Thanks for help.

Florent

 

[Larry Barowski]

Hello,

I have an application Java who is bounded to 64Mb.
This application instanciate a certain numbers of objects to attain about
30Mb a
thrown time.
On some actions, the application instanciate again the same objects.
The used memory increases in consequence.
First objects are not more referenced.
...

They probably are referenced, either because of your mistakes or
because of bugs in Swing. Make sure you remove any listeners
that are external to the unused objects, and if you have frames or
modal dialogs make sure they are "dispose()"ed, not just hidden.

What version of Java are you using? Try doing a setJMenuBar(null)
when you are finished with JDialogs and JFrames that have menu
bars, and see if they are then finalized. Also, download a tool that
allows you to examine memory. "jmp" is a fairly decent free one -
not very stable but I can usually get it to work after a few tries. It
doesn't show paths-to-root, but you can trace down the
"user tree" to find the problem (your problem or Swing's).

-Larry Barowski

 

[Florent Coué]

Thank you for your response.
After have a look on my code, I have another question :
In my application, I use a JFrame with a JMenuBar
and in my JFrame with a specific action X of the menu, I instanciate and
show a JInternalFrame (who contains many Swing object : JTabbedPane, JTable,
JList, ...) and with another specific action Y of the menu, I remove and
dispose the JInternalFrame.
The JInternalFrame is displayable only once. But each time, I do action X,
action Y, action X and so on, I instanciate again the JInternalFrame (and
all the sub components) and the used memory increase. Normally, I have only
one referenced JInternalFrame and I hoped that the garbage collector did its
work on all the Swing component no more referenced.
My question is : Is it advised to instanciate again Swing components in an
GUI application (hoping a good garbage collection) or is it better to
instantiate all the Swing components at start of application and reuse the
same Swing component ?
I hope my explanation is enough clear.

Thanks for help

 

[Larry Barowski]

Thank you for your response.
After have a look on my code, I have another question :
In my application, I use a JFrame with a JMenuBar
and in my JFrame with a specific action X of the menu, I instanciate and
show a JInternalFrame (who contains many Swing object : JTabbedPane, JTable,
JList, ...) and with another specific action Y of the menu, I remove and
dispose the JInternalFrame.

First, make sure nothing external references the internal frame,
and that the internal frame is not a listener and does not have a
listener for anything outside itself.

Try this sequence - it should work for all J2SDK 1.3 and up:
internal_frame.setVisible(false);
desktop.getDesktopManager().closeFrame(internal_frame);
desktop.remove(internal_frame);
internal_frame.dispose();

Your desktop may sometimes hang on to one previous internal
frame due to some selection or focus mechanism, but a GC
should free all the rest. This doesn't happen on all Java versions -
I'm not sure about 1.4.1_02. To help free up memory for an
internal frame that is not released, immediately after the
setVisible(false), do:
internal_frame.setContentPane(new JLabel());
and if your internal frames have menu bars:
internal_frame.setJMenuBar(null);
and null out any of your own fields that might hold a significant
amount of memory, after the dispose().

-Larry Barowski