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

Boehm, Hans hans.boehm at hp.com
Wed Jan 21 18:02:12 EST 2009

From: javamemorymodel-discussion-bounces at cs.umd.edu [mailto:javamemorymodel-discussion-bounces at cs.umd.edu] On Behalf Of Joe Bowbeer
Sent: Wednesday, January 21, 2009 1:56 PM
To: concurrency-interest; javamemorymodel-discussion
Subject: Re: [Javamemorymodel-discussion] [concurrency-interest] Fences.keepAlive

More related to keepAlive:

1. Names

 I think one of the "until" names better conveys what it is trying to do.


Though I would be even more comfortable if a Runnable were used to define the scope:

  doWithStronglyReachableReference(ref, runnable);

Is that possible?  Or is there a chicken-egg problem?

It seems possible to me.  But I have two concerns:

 1.  Unlike the other fences, I think we want to encourage use of keepAlive, or whatever it ends up being called.  It may be ugly, but the alternative is usually wrong,which is worse.  This means we want to make it as easy to use as possible, and this seems to make it syntactically quite heavy.  I would expect correct code to use this several times per finalizable class
 2.  We want to add keepAlive in large part because synchronized(this){} is much slower than it needs to be for this (ab)use.  And there is no good argument that keepAlive won't end up on a frequently executed code path.  Do we believe that common implementations will optimize out any overhead associated with the Runnable?  If I understand this correctly, the expected use will involve allocating and constructing the runnable each time.  Construction presumably sets up a method table, which might require a fence.  Thus a naive implementation seems to add significant overhead, which one might avoid with escape analysis etc.  But if implementations don't actually perform those optimizations, we still have a problem.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090121/fe27df61/attachment-0001.html>

More information about the Concurrency-interest mailing list