See /home/jeff/MemLeak for examples.


I've found why I eventually run out of memory -- my JInternalFrame
subclasses are not getting garbage collected. All the objects they
themselves use *are* getting collected, including Panels and Listeners.
Since my codebase has no leaks in 1.1.5 (Swing 0.7), then there is something
new in 1.2's Swing that my codebase should be using but isn't.

Put another way: Are there any new mechanisms in the 1.2 Swing that
maintain references to JInternalFrames that weren't present in 0.7? If so,
what's the method to call to trigger these mechanisms so these references
are released? Taking a guess -- do I need to call
JFrame.getContentPane().remove(<myJInternalFrame>) -- or is this implied by
<myJInternalFrame>.dispose()?

There may be some method/pattern I should be calling/following, but ain't.
And it may be that this oversight is harmless in 1.1.5/0.7 but critical in
1.2.

In the meantime, I'm going to insert a superclass below JInternalFrame but
above my existing JInternalFrame subclasses. In this new middle-man class,
I'm going to implement setClose, dispose, etc, to print diagnostics before
calling the equivalent superclass method. Hopefully this will reveal
something interesting.

Dave

p.s. The effective debugging paradigm that helped me finally gain this
insight goes as follows:

(1) At program start, create a static Hashtable.
(2) In the constructors of interesting classes, insert into this hashtable:
     hash.put(this.hashCode(), "Instantiated: " + this.getClass().getName()
+ " [" + toString() + "]");
(3) In the finalizers of these classes, update this hashtable:
     hash.put(this.hashCode(), "Finalized: " + this.getClass().getName() + "
[" + toString() + "]");
(4) At appropriate moments, print this hashtable:
     (a) If any instance of a given class ever gets finalized, then all such
instances are (eventually) eligible for finalization.
     (b) If any class never has any finalized instances, then something
somewhere is maintaining a strong reference to it.
     (c) Since the hashtable keys off of hashCode, it does not itself
maintain a reference. I suppose a Weak Hash would work also.

--- Additional information from David:

Attached are two HAT-generated HTML files. One is the "object instance"
page of a JInternalFrame subclass that refuses to be garbage collected. The
"References to this object" section of this page includes *no* references
coming from my code. The other HTML file is the "rootset references" page
for this same instance. *None* of the reference paths mention my code.

Based on these results, I believe either (a) there is an object retention
problem in Swing, or (b) there are method(s) I need to call to release these
remaining references. If (b), I hope that the attached files will help you
guys help me identify what these method(s) are.

*Phew* Well, it took me 1-2 weeks to arrive at this conclusion, and based
on these results, I believe there is nothing more I can do to my code to fix
my rapidly-occurring OutOfMemory problems until I get feedback from you
guys. So I eagerly await any feedback.

I can readily provide any other HAT-generated pages on request. (I'll keep
the HAT server running on our Solaris box.) I can also send the subset of
our code required to duplicate the problem, if necessary. (This second
option will require a moderate bit of telephone-time to help walk someone
through the configuration and debugging process for our code.)