[concurrency-interest] Significance of volatile static

Mohan Radhakrishnan mohanr at fss.co.in
Thu Jun 23 01:01:16 EDT 2011

I think I understand. It is just a way of ensuring the happens-before


It think it cuts both ways. When code that uses finalizers are broken in
critical applications then it is serious. But techniques like this have
to be understood well by programmers with less experience before they
use them. Or else it is even more serious ! AFAIK developers are not
even aware about these points when working with a single CPU. Now I have
suddenly started using multi-core HP Blade servers for our Java


Do these rules apply to Weak references ? As I understand they are also
a useful technique.






From: Boehm, Hans [mailto:hans.boehm at hp.com] 
Sent: Thursday, June 23, 2011 5:30 AM
To: Mohan Radhakrishnan; concurrency-interest
Subject: RE: Significance of volatile static


(A version of the slides are at
f .  I couldn't immediately find the official JavaOne version anymore.)


The intent here is that you declare, say, "volatile static sv;" in the
class with the finalizer, and then use


sv = this; sv = null;


at any point at  which you want to endure that the object is still
considered reachable for finalization purposes, i.e. where keepAlive()
is called.


The finalizer then reads sv.  This ensures that there is a
happens-before relationship between the assignments and the finalizer,
effectively preventing the finalizer from running too early.


This is about as ugly and disgusting as the solution based on
synchronized, with the added misfeature that it introduces lots of cache
contention, since everybody is writing to the same static variable.
Hence it's likely to make your application completely unscalable, if it
wasn't already.


As far as I know, a real  fix for this has unfortunately never made it
into the language specification.  (Doug?)  Doug had a proposal as part
of the fence proposal.  But I think it ended up as collateral damage of
that debate.  The current solutions to this problem are all both ugly
and slow.  It's not hard to add something like keepAlive() to the, and
make the result just ugly.  To also get rid of the ugliness we would
need to stop the compiler from eliminating dead reference variables, at
least in some contexts.  This would involve a smallish slowdown in a lot
of code in order to support a fairly esoteric feature (finalizers and
weak references).  Whether this is worthwhile is open to debate.


As it stands, I suspect little real code uses any of these techniques,
and a lot of (most?) Java code using finalizers or weak references is
still broken.  But it works correctly most of the time, especially on




From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Mohan
Sent: Tuesday, June 21, 2011 9:56 PM
To: concurrency-interest
Subject: [concurrency-interest] Significance of volatile static




        I have read the presentation "Finalizers, Thread and the Java
memory model" by Hans J. Boehm and I can't claim to understand
everything but I have a question. 


I am a beginner and I am trying to understand what the author means by
this statement.

    "Store reference to object into volatile static, then

immediately clear it"


Is there any particular semantics associated with 'volatile static' and
the way it is used in this context ?






Reachability, visibility solutions

 We want something that

 Ensures reachability

 Synchronizes to create a happens-before relationship

between ordinary methods and finalizer.

 Options provided by JSR133:

 Store into volatile field in ordinary method.

 Read field in finalizer.

 Store reference to object into volatile static, then

immediately clear it.

 Read volatile static in finalizer.

 Release lock on object at end of ordinary method.

 Acquire lock at beginning of finalizer.

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

More information about the Concurrency-interest mailing list