[concurrency-interest] Volatile array and Wait
mike.skells at ebizz-consulting.com
Fri Oct 21 08:44:56 EDT 2005
> -----Original Message-----
> 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,
> through the
> > 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 ;-)
> David Holmes
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest