[concurrency-interest] Volatile array and Wait
Pete.Soper at Sun.COM
Fri Oct 21 11:11:19 EDT 2005
Mike Skells wrote:
>>From: concurrency-interest-bounces at cs.oswego.edu
>>[mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf
>>Of David Holmes
>>Sent: 20 October 2005 15:59
>>To: concurrency-interest at altair.cs.oswego.edu
>>Subject: RE: [concurrency-interest] Volatile array and Wait
>>Mike Skells writes:
>>>On the consideration of a no op ...
>>> volatile Object b = new Object; ...
>>> b = b; // volatile write
>>>Isnt the compiler/jit liable to remove the b=b statement,
>>>normal rules of elimination of redundent code, or is this
>>>barred for volatile variables
>>It can't remove the memory synchronization actions, even if
>>it could eliminate the "code".
>>>Similarly if a variable is never read, or never written, and is
>>>private then it can be eliminated cant it
>>Depends how absolute "never" is :) There are various
>>ahead-of-time building tools that purge unused fields and
>>code from class files using whole-program analysis - and
>>presume no reflective (or jni) access :). Not sure a jit
>>would ever get involved with this though.
> My point for both of these issues is not whether a JIT _does_ make these
> tranformations, as much as is there a _specification_ that stops a JIT, java
> compiler, or AOT, AOP, or native compiler for that matter, from making that
> transformation. If the limitation is just in the current implmentation then
> it is unsafe.
> I cant remember seeing such a specification anywhere, although there is a
> lot of documentation out there ;-)
And sometimes hard to find. Some old links for the relevant specs seem
to have been made ineffective, but try this one:
See sections 184.108.40.206 and 17.4.5, especially the discussion item in the
"A write to a volatile field happens happens before every subsequent
read of that field."
This doesn't say "if the read or write doesn't get optimized away." This
text isn't making a suggestion. In general compilers can't eliminate
volatile accesses. Cases like reflective inspection have to be covered,
as David Holmes mentioned, and this simply can't be anticipated (in the
sense of being ruled out) except in very special cases. And as somebody
else mentioned, volatile references impose strict constraints on code
motion (rearrangement of instruction ordering by a compiler). And
David's remark about even "b = b" having to preserve the memory sync
action is an important point: ignore the right hand side when trying to
understand this code vis a vis concurrency.
I'm cautiously optimistic that the Java spec has this area covered now,
thanks to all the JCP and other work that went into its improvement. :-)
By the way, compilers for older languages like C have had to deal with
volatile too and this understanding has fed forward into Java. A
proportion of C programmers have discovered the importance of volatile
declarations when they encounter industrial strength optimizers. An
extreme case of this was Encore Computer's C compiler that could do
automatic parallelization of loops (e.g. making the outermost possible
loop run iterations in parallel with multiple threads). The burden on
the optimizer to not "screw up" instruction reordering like hoisting
invariants, etc, was very high. But if the programmer misunderstood the
need for volatile declarations the program would often fail when run in
parallel (and of course a bug was filed against the "broken compiler").
>>Concurrency-interest mailing list
>>Concurrency-interest at altair.cs.oswego.edu
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest