[concurrency-interest] Significance of volatile static

Geert Denys gdenys at yahoo.com
Mon Jun 27 09:12:25 EDT 2011


Hans,

We have seen this problem here, too. One test was failing fairly regularly on an 8 core build machine with a mysterious NPE. We weren't able to reproduce it easily on our own 4 core workstations. After a while we realized the finalizer of the object had been run, while another thread was still executing within a method of that object... It sounded hard-to-believe, but then I stumbled upon your paper and slide 31 was exactly the problem we were facing (even the methods names were almost the same:).

Regards,
Geert.


________________________________
From: "Boehm, Hans" <hans.boehm at hp.com>
To: Mohan Radhakrishnan <mohanr at fss.co.in>; concurrency-interest <concurrency-interest at cs.oswego.edu>
Sent: Thursday, June 23, 2011 7:42 AM
Subject: Re: [concurrency-interest] Significance of volatile static


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.
 
Hans
 
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.
 
Thanks,
Mohan
 

________________________________

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.
 
Hans
 
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
 
Hi,
 
        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 ?
    
Thanks,
Mohan
 
 
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.
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110627/07d3e2f2/attachment.html>


More information about the Concurrency-interest mailing list