>I'm busy fixing volatiles in HotSpot.
OK, here are the things that need to be enforced. I'm only going to
give rules for Sparc TSO, IA-64 and IA-32 (see footnote).
The following things need to be enforced for the existing semantics:
* reads/writes of volatile longs/doubles are atomic. I'll let you work out
the code needed to implement this, but probably requires that volatile longs
and doubles be 8-byte aligned.
* reads/writes of volatile variables are sequentially consistent. Implications:
- the compiler must not reorder accesses to volatile variables (including
two reads)
- appropriate memory barriers need to be inserted. On TSO and IA-32, that
requires a memory barrier between a write to a volatile and following
read of a volatile. For IA-64, see below.
* reads/writes of volatiles may not be moved into synchronized blocks
* reads/writes of volatiles may not be moved out of loops
In addition, we are proposing that a volatile write be treated as a release,
and a volatile read be treated as an acquire. Implications:
* In the compiler, you may not reorder any memory access and a following
volatile write. You can treat a volatile write similarly to a monitorexit
as far as reordering. For example, all stores delayed and cached in registers
must be flushed immediately before you execute a volatile write.
* In the compiler, you may not reorder a volatile read and any following
memory access. You can treat a volatile read similarly to a monitorenter
as far as reordering. For example, all memory values cached in registers
must be reloaded immediately after you execute a volatile read.
* You need to generate appropriate memory barriers. On TSO and IA-32, no
additional memory barriers need to be generated. On IA-64, volatiles
should be implemented using ld.acq and st.rel instructions, but you also
need a memory barrier between a volatile write and a volatile read
(to enforce
sequential consistency of volatile memory accesses).
IA-32 footnote:
The IA-32 rules are a little tricky, because it changes from chip to
chip and system to system. Intel will not make any guarantees about
the memory model supported by IA-32 systems. So we are forced to
guess.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:28 EDT