So far, it has been pointed out that the Alpha, PowerPC, and IA-64
architectures support "aggressive reordering" that allow processors to
change the order in which the writes of one processor become visible
to another processor. Thus, if processor one writes "v1" into "x" and
then "v2" into "y", and processor two subsequently reads "v2" from
"y", then processor two is not guaranteed to see "v1" in "x" unless
there is a memory barrier between the two stores on processor one
_and_ a memory barrier between the two reads on processor two.
It has also been pointed out that this form of aggressive reordering
may make it difficult to implement "fast, safe object-oriented
languages."
Bill Pugh points out that aggressive reordering has implications for
initializing object headers: when reading the header of an object
created by another thread, how do you're reading valid data. Pugh
asks:
> [Agressive reordering] makes access to object headers, including
> virtual method tables, unsafe in the presence of data races. I don't
> believe this acceptable.
> Do you:
> * believe it is acceptable to make it unsafe, or
> * believe it is not unsafe?
> * believe it acceptable to insert memory barriers before each
> access to an object header?
I don't believe it's acceptable to make the language unsafe, nor is it
acceptable to insert memory barriers before reading virtual method
tables. There are techniques for dealing with object headers that are
both safe and avoid barriers. Bill himself has pointed out the basis
of these techniques: start with "pre-zero'd" pages. If a vtable is
accessed before it's visible, arrange to replay the access in the
null-dereference handler. Other fields in the object header are
manipulated at GC time, where there are other synchronization options.
Dealing with object headers is a pain, but it's bareable. But
changing the Java semantics to allow readers to read data without
synchronization would not be bareable. The techniques for dealing
with object headers are tedious but the do not affect performance.
However, I don't see a way of implementing the synch-free-read
semantics in a cheap manner; it would require many reader-side memory
barriers, which would kill performance.
> Does anyone know about the actual [Alpha] implementations? The
> specifications of memory models are often far more aggressive than
> the current implementations, to allow future designs headroom.
I've asked around here at SRC, and those who should know say that
existing implementations do not appear to do the kind of reorderings
that cause trouble. This is based on experience with these machines,
not on familiarity with the chip designs. However, these people also
say that future implementations definitely _will_ do these
reorderings.
Alpha aside, if we look out into the future, there's a strong
possibility that NUMA architectures will begin to enter the
mainstream. The kind of aggressive reorderings we are talking about
now will become even more valuable for NUMA machines.
The object-header problem is tedious but manageable. But changing the
Java semantics to allow unsynch'd reads would be a real pain. Why
make life difficult for people implementing Java on the Alpha,
PowerPC, IA-64, and, in the future, aggressive NUMA machines? As
argued in a separate thread, the unsynch'd idiom is not worth it!
Raymie
(*) Dan Scales points out that, on the IA-64, one could use the st.rel
and ld.acq instructions to avoid the memory barriers. It's too early
to know what might be the performance characteristics of these
instructions. I would bet there will be a substantial performance
penalty.
-------------------------------
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email majordomo@cs.umd.edu and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:13 EDT