gjavah and volatility

Fri Jan 26 20:18:00 GMT 2007

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.
>