[concurrency-interest] [Javamemorymodel-discussion] Fences.keepAlive

Hans Boehm Hans.Boehm at hp.com
Wed Jan 21 13:41:19 EST 2009

On Wed, 21 Jan 2009, Gregg Wonderly wrote:

> Maybe I'm still not getting what the underlying issue is.  I thought we were
> talking about the fact that because there were no other visible references that
> the Compiler/GC might decide on actions that would cause the object to be made
> eligible for GC.  So, to me releaseHere(), or doneUsingReference() or
> holdThisUntilHere() or some such is the control that we are trying to put in
> place.  Am I still missing something?
The problem is that the reference may or may not be used again later in
another method call.  If it is used again later, we expect keepAlive()
(or whatever) to be a no-op, since the object can't be finalized yet
anyway.  But releaseHere() implies that we are definitely done with the
reference, and it's OK to garbage collect the object.

In the case in which this actually is the last use, those names seem OK,
except that the object might still not be finalized until much later.

Although I don't like releaseHere(), the other two, or just 
holdUntilHere(), sound fine to me.  The one diasadvantage is that
the CLR already seems to use keepAlive().  But that may not be
a major concern.

As far as the description is concerned, I wonder whether we can and should
do a complete job in the javadoc.  We should clearly do as well as we can,
but this is a fairly fundamental problem with finalizers and weak 
references.  In the long run, I think this really needs to be addressed
in textbooks, and possibly in the description of finalize() in the JLS.
It seems to me the problem is not so much that people don't understand
the meaning of keepAlive(), as that they are starting from incorrect
assumptions about how finalization works, and hence don't understand the
need for it.


More information about the Concurrency-interest mailing list