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

Jason T. Greene jason.greene at redhat.com
Wed Jan 21 14:48:10 EST 2009

Hans Boehm wrote:
> 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.

IMO keepAlive() is a good name that is easy to understand.

Jason T. Greene
JBoss, a division of Red Hat

More information about the Concurrency-interest mailing list