RE: gjavah and volatility

["Boehm, Hans" <hans dot boehm at hp dot com>]

There is a lot of discussion of things like Java volatile implementation
at

http://g.oswego.edu/dl/jmm/cookbook.html

There is also continuing discussion of some of the fine points, but I
believe the above page reflects what's commonly done.

On X86, the major differences are probably:

- longs and doubles need to be updated and read atomically for Java.

- A Java volatile store will often need a trailing fence (e.g. cpuid or
xchg or locked instruction. or mfence on newer processors) in order to
prevent hardware reordering with a following load.  (According to the
documentation, I think _sync_synchronize() should do this, but last I
checked it didn't.  I think that's a bug, but it's not clear it's
fixable, since all of these instructions are very slow, and most uses of
__sync_synchronize() don't require them.

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] 
> On Behalf Of Andrew Haley
> Sent: Friday, January 26, 2007 11:56 AM
> To: Tom Tromey
> Cc: java@gcc.gnu.org
> Subject: Re: gjavah and volatility
> 
> Tom Tromey writes:
>  > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
>  >
>  > Andrew> This in Java:
>  > Andrew>   static volatile SecurityManager current;
>  > Andrew> generates this in CNI:
>  > Andrew>   static volatile ::java::lang::SecurityManager * current;
>  > Andrew> but of course the object isn't volatile, the field 
> is.  It should be
>  > Andrew>   static ::java::lang::SecurityManager * volatile current;
>  > Andrew> shouldn't it?
>  >
>  > Yeah, oops.  But do we even want to translate java 
> volatile into c++  > volatile?
> 
> Very much, yes.  
> 
> I realize the Java volatile is stronger than the C++ 
> volatile, and therefore in theory we need locked accesses, 
> but volatile is better than nothing.  (I note with some 
> sadness that if we'd decided to provide accessor methods for 
> all BC-ABI accesses to fields then this would "just work" 
> because from CNI code we'd call the accessor.  Ho
> hum.)
> 
> Andrew.
>