RE: Fibonacci and performance

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

> I think Java volatile is sufficient, but not C volatile.  
> Unfortunately
> gcj doesn't currently do anything for volatile.  (There was 
> once a PR to
> that effect.)  For that matter the backend is ignorant of 
> synchronization.
> GCC doesn't have any way to describe memory barrier, etc. 
> instructions in
> the machine description.
> 
On Itanium, gcc generates ld.acq and st.rel for loads and stores of
volatiles.  I think for this to make sense, it would also have to inhibit
advancing memory references at compile time past the ld.acq or delaying them
past st.rel, which I think should be sufficient to handle this case.  Does
it?

This of course is not required by the C spec., nor does it say a lot about
other architectures.  But if it's doing this right, then the C
implementation should be very close to what's required by the proposed new
Java memory model.

The new model of course also still requires atomicity for longs and doubles.
But that's free on Itanium and Alpha Linux.  It seems to require locking
around long and double volatile accesses on 32-bit platforms.  I think that
with hash synchronization, it ould work to use _Jv_MonitorEnter on the
address of the long or double.  It wouldn't add unnecessary contention, but
it wouldn't be fast either.  I don't think I know how to do this fast,
except perhaps on a uniprocessor.

Hans