References remain on Thread stack

[jshirah at ibm.net (Joe Sam Shirah)]

    Hi David,

    You might take a look at

http://developer.java.sun.com/developer/technicalArticles/ALT/RefObj/index.h
tml

especially the note that mentions

"NOTE: The im object is set to null because there is no gurantee the stack
slot occupied by it will be cleared when it goes out of scope. A later
method invocation whose stack frame contains the slot previously occupied by
im might not put a new value there, in which case, the garbage collector
still considers the slot to contain a root.

This is a problem even with non-conservative exact collectors. As a
precaution, you can increase the probability that an object will become
softly, weakly, finalizable, or phantomly reachable by clearing variables
that refer to it."

    This is very similar to the issue you are addressing.  im is local to
the method discussed.  The lesson seems to be, set even local variables to
null when gc issues arise.



                                            Joe Sam Shirah
                                            Autumn Software


-----Original Message-----
From: David Soroko <davids@xxxxxxxxxxxxxxxx>
To: advanced-java <advanced-java@xxxxxxxxxxxxxxxx>
Date: Tuesday, August 31, 1999 1:51 PM
Subject: References remain on Thread stack


>References remain on Thread stack
>
>Suppose I have daemon Runnable whose run() looks like this:
>
>
>public void run()
>{
> while( !_stop )
>      {
>          waitForSomeConditionToBecomeTrue();
>          doSomeWork();
>      }
>}
>
>Now, in the doSomeWork() method local variables are created. The behavior
>that I see is that between iterations of the while loop, these variables
are
>never GCed. The profiler I am using (OptimizeIt) indicates that these
>local variables remain on the thread's stack. This is a concern to me
>since these variables potentially occupy a lot of memory and there can be
>long intervals of time between the while() iterations.
>
>Is there a way to purge the thread's stack of references? Is this the
>officially correct behavior of the GC?
>
>============================================
>David Soroko
>mailto://davids@xxxxxxxxxxxxxxxx
>http://www.geocities.com/SiliconValley/Campus/1628/
>Group Manager, Core Technologies
>Manna Inc.
>============================================
>