JavaMemoryModel: 8/3 Bay area trip report

From: Bill Pugh (
Date: Mon Aug 09 1999 - 14:26:13 EDT

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

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

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

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

        instructions where stale values in object header could cause problems:
        array load store/load throwing an inappropriate
IndexOutOfBounds or ArrayStoreCheck exception

strong class initialization safety -
        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

Bill Pugh
JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:18 EDT