[concurrency-interest] Volatile array and Wait

Mike Skells 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[50]; ...
> >   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 
> explicitely 
> > 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
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> 




More information about the Concurrency-interest mailing list