[concurrency-interest] Significance of volatile static

Boehm, Hans hans.boehm at hp.com
Thu Jun 23 01:42:32 EDT 2011

This problem also applies to java.lang.ref, since that can also be used to perform finalization-like actions, and the target of a weak reference may also appear unreachable while one of its methods is still running.

I'm not sure that multicores affect this problem fundamentally.  It can happen if you garbage collect at the wrong point on a uniprocessor, and then immediately switch to the finalization thread.  Perhaps it is easier to observe on a multicore processor, but I'm not sure.  I suspect it's rare and obscure enough that most observed failures are misattributed to alpha particles or the like.  A few weeks after I gave the talk someone within HP did point out that it finally explained an obscure problem they had been observing.


From: Mohan Radhakrishnan [mailto:mohanr at fss.co.in]
Sent: Wednesday, June 22, 2011 10:01 PM
To: Boehm, Hans; concurrency-interest
Subject: RE: Significance of volatile static

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

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 applications!!!!

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 http://www.hpl.hp.com/personal/Hans_Boehm/misc_slides/java_finalizers.pdf .  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 x86-32.


From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Mohan Radhakrishnan
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/fbe41763/attachment.html>

More information about the Concurrency-interest mailing list