[concurrency-interest] Significance of volatile static

Boehm, Hans hans.boehm at hp.com
Wed Jun 22 19:59:41 EDT 2011

(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/20110622/87bf10cd/attachment.html>

More information about the Concurrency-interest mailing list