I visited DEC SRC and Sun Microsystems on Tuesday, August 3rd.
At DEC, I talked with Sanjay Ghemawat, Kourosh Gharachorloo, Dan
Scales, Raymie Stata. At Sun, I talked with Josh Bloch and Tim
Lindholm.
I've given them a brief chance to look this over, but my report may
still have errors either in my summary of our discussions or my
proposals.
Here is a summary of what was discussed (2 more messages follow):
Safety guarantees (defined in more detail below):
* Everyone agreed that type safety and out-of-thin-air safety must
be absolute.
* Everyone agreed that some form of VM safety guarantee was needed;
the Dec people thought that weak VM safety was more appropriate, but
didn't seem to have strong opposition to strong VM safety. the Sun
people insist on strong VM safety.
* Everyone was happy with requiring strong class initialization safety.
* For "properly synchronized programs", you get sequentially consistent
semantics. (Some research papers try to define "properly synchronized
programs" -- we'll see what we need to do here).
* Initialization safety:
Everyone agrees that there must be a way to construct a class
that is guaranteed to be atomic and immutable, so that data races
cannot allow someone to see an instance change.
Other than that, people disagreed. This is the primary (only?) point
of disagreement. See a separate message for a discussion of
initialization safety.
Changing the semantics of Volatile:
* Reading/writing a volatile field should have acquire/release semantics, and
also not be cachable or reorderable with other volatile memory
operations. If thread 1 writes to a volatile field, and then thread 2
reads that field and sees the value written by thread 1, thread 2 must
see all writes performed by thread 1 before the write to the volatile
field.
Changing the semantics of locks:
It has been suggested that we change the semantics of locks/volatiles so that
writes only need to be communicated from thread 1 to thread 2 if
thread 1 has released a monitor/volatile that is later acquired by
thread 2.
Amoung other implications, recursive locks and locks on thread
local objects now become no-ops rather than memory barriers.
A more technical write up of this will be coming.
This change is tricky. People might have written to the existing
standard in a style that won't be supported by the new standard. But
there was agreement that any such style is a very dubious style.
Definitions of safety guarantees
type safety - obvious
not-out-of-thin-air safety (excluding longs and doubles)
Any value you read from a field or array must be a value written by
some thread to that field or array element (including the initial
write of the default-value)
VM safety - involves all the bad things that could happen because you
see a stale value in an object header or in the class data structures
(i.e., anywhere other than an array element or a field)
weak - seeing a stale value might cause a DataRaceException
to be thrown
strong - seeing stale values in VM structures must not have
any semantic
effect
instructions where stale values in object header could cause problems:
invokevirtual
arraylength
array load store/load throwing an inappropriate
IndexOutOfBounds or ArrayStoreCheck exception
instanceof
checkedcast
strong class initialization safety -
add INVOKEVIRTUAL, INVOKESPECIAL, GETFIELD & PUTFIELD to instructions
that require a class to be initialized
Make clear that if you check that a class is initialized, seeing
that the class has been initialized by another thread must involve
seeing all writes done by the thread that initialized the class.
If a thread creates an instance of a class during the initialization
of that class and publishes a reference to that instance, then other
threads may see incomplete results of the class initializer, but they
are still guaranteed to see a consistent view of the class
internal data
structures (required by VM safety).
My idea about how to implement this efficiently will follow in a
message.
Bill Pugh
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:18 EDT