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

Gregg Wonderly gregg at cytetech.com
Wed Jan 21 15:27:21 EST 2009

Jason T. Greene wrote:
> 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.

I won't argue that its a good name and easy to understand.  What I'm suggesting 
is that it feels more like it initiates and action at that point in the code 
rather than deferring an action until that point in the code.  With 
documentation and such, it would probably work.  I'm still worried about the 
readability of code being weakened because it doesn't really show a delimited 
block of code in an intuitive way.  Given all the other things we do with 
start*(), end*() and blocks as in synchronized(...) { ... } etc. it feels like 
there needs to be something really "good" chosen as the name to make it clear 
what it implies.  Adopting the CLR chosen name, might be advantageous for those 
doing CLR based development, but I'm not sure it's the best choice.

Gregg Wonderly

More information about the Concurrency-interest mailing list