Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.gui > #1976

Workaround for JDialog me

Show key headers only | View raw

  To: comp.lang.java.gui
I just submitted a bug report on a memory leak that I discovered in 1.6 (I 
tested with 1.5 and there is no memory leak). What I am wondering is if 
anyone has encountered this bug and if so if there is any better workaround 
which I will describe shortly?

Basically one would first create a JFrame and then have a modal child dialog 
(e.g,. PrimaryChildDialog) hanging off of it and then create another modal 
child dialog (e.g., SecondardChildDialog) which hangs off the first modal 
child dialog. Now one would close/dispose SecondaryChildDialog and then 
close/dispose PrimaryChildDialog and then set PrimaryChildDialog to null.

Now if one repeats the above process n times one would see n 
PrimaryChildDialog objects occupying memory (i.e., 
PrimaryChildDialog.finalize method never gets called and it is also returned 
in the array of Window objects from the Windows.getWindows() method).

For example here is a code snippet for creating/showing and then disposing 
PrimaryChildDialog:
public void openPrimaryChildDialog ()
{
 fPrimaryChildDialog = new PrimaryChildDialog(getFrame (),
   "Primary Child Dialog...", true);

 fPrimaryChildDialog.openDialog ();

 fPrimaryChildDialog.dispose ();

 fPrimaryChildDialog = null;

 // Note: there should be a better way of causing Java to IMMEDIATELY
 //       release the fPrimaryChildDialog resource! ==> Ugh!
 getFrame ().dispose ();

 Runtime.getRuntime ().runFinalization ();

 getFrame ().setVisible (true);
}

In Java 1.5 PrimaryChildDialog's finalize method is correctly called each 
time but in 1.6 there are n instances of PrimaryChildDialog and its finalize 
method is never called. Oh yes, I got the following cool piece of code to 
guarantee that the memory was indeed flushed which I called everytime I 
disposed of PrimaryChildDialog:

private void flushMemory(PrintStream pPrintStream)
{
 pPrintStream.println ("\nFlush memory begin:");

 //Use a vector to hold the memory.
 Vector v = new Vector();
 int count = 0;
 //increment in megabyte chunks initially
 int size = 1048576;

 //Keep going until we would be requesting
 //chunks of 1 byte
 while(size > 1)
 {
  try
  {
   for (; true ; count++)
   {
    //request and hold onto more memory
    v.addElement( new byte[size] );
   }
  }
  //If we encounter an OutOfMemoryError, keep
  //trying to get more memory, but asking for
  //chunks half as big.
  catch (OutOfMemoryError bounded){size = size/2;}
 }

 //Now release everything for GC
 v = null;
 //and ask for a new Vector as a new small object
 //to make sure garbage collection kicks in before
 //we exit the method.
 v = new Vector();

 // Let's run gc anyhow...
 Runtime.getRuntime ().gc ();

 pPrintStream.println ("\nFlush memory end.");
}

The only workaround that I could think of is to minimize the memory impact 
by calling the JDialog's getContentPane().removeAll () method as well as any 
hard references in the class which I extended so that at least those items 
can be garbage collected.

Does anyone have any better workaround and has anyone encountered this 
problem?

If anyone is interested I can send the small test case (4 small Java files) 
that I just submitted to Sun.

Karl

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

Back to comp.lang.java.gui | Previous | Next | Find similar | Unroll thread

Thread

Workaround for JDialog me "Karl Mueller" <karl.mueller@THRWHITE.remove-dii-this> - 2011-04-27 15:36 +0000

csiph-web