JavaMemoryModel: Draft JMM Synopsis

From: Doug Lea (
Date: Sun Feb 29 2004 - 18:19:58 EST

I've been putting together a synopsis of new JMM to someday appear in
a section in the 3rd edition of CPJ book. My intent here is to keep it
short, yet complete enough to be suitable for putting on facing pages
of book to keep open by people writing code that depends critically on

Unlike the (very nice) stuff Jeremy Manson and Brian Goetz have been
putting out lately, this section is designed as a cookbook for
non-novice concurrent programmers. (Whatever that means!) It mostly
deals with orderings, since most other aspects will be covered
elsewhere. Also, other subsections (not yet written) will include more
explanatory text; this is just the synopsis. (Note also that this
includes references to some JSR166 stuff too.)

I'm posting this hoping that someone will see problems or have
suggestions for improvement.


The Java memory model (JMM) deals mainly with the "memory actions" of
a program -- loads, stores, locks, and unlocks -- where a completed
store action modifies (only) the variable being written, and a
completed load action obtains a value from a completed store action
that does not occur after this load. The notion of a "completed"
memory action reflects the possibility that the effects of some
actions may occur in a different order than they are issued. Loads
and stores for all kinds of variables except non-volatile longs and
doubles are atomic.

Some aspects of the model apply only to subcategories of memory actions:
  NORMAL accesses are lads and stores to non-volatile, non-final (static or
      nonstatic) fields and array elements.
  VOLATILE accesses are loads and stores to volatile (static or nonstatic)
      fields. Additionally, java.util.concurrent.atomic compareAndSet
      operations act as volatile accesses.
  FINAL accesses are loads and stores to final (static or nonstatic) fields.
  LOCKS and UNLOCKS are entries and exits of synchronized blocks or methods
      The same rules apply to operations on java.util.concurrent.locks.

The JMM allows the memory actions in a program to be performed in
parallel or out of order, subject to the following:

General constraints

  * The within-thread expression and statement evaluation dependencies
    specified in the Java Language Specification (JLS) are at all
    times honored, consistently across all threads. (Rigorously
    specifying what is meant by "consistently" in cases that
    entail apparent circularities and the like turns out to be
    challenging. See JLS chapter 17 for details.)

  * A memory action by one thread that cannot influence the actions of
    any other thread need not have any memory effect, and can thus be
    excluded from remaining rules. (See JLS for a detailed explanation
    of "influence".)


  * The initial action for any field is a store of its default (zero
    or null) value. This must complete strictly before any loads of
    this field by any thread.

  * Any FINAL store to a static final field must complete strictly before
    any load of this field by any thread. (There are special
    exceptions for setting System.{in,out,err}.)

  * Any FINAL store to a nonstatic final field by a thread must complete
    strictly before any subsequent store of a reference to the new
    object with this field by that thread.


  * A NORMAL access by a thread must complete strictly before those of
    any subsequent VOLATILE store or UNLOCK by that thread.

  * A load of a reference to an object by a thread must complete
    strictly before any subsequent load by that thread of any of this
    object's FINAL fields.

  * A VOLATILE load, LOCK, or compareAndSet by a thread must complete
    strictly before any subsequent memory action by that thread.

  * A VOLATILE store or UNLOCK by a thread must complete strictly
    before any subsequent VOLATILE access, LOCK, or UNLOCK by that

  * A weakCompareAndSet to a variable by a thread must complete
    strictly before any subsequent access to that variable by that
    thread. (Note: All other memory operations on any variable for
    which weakCompareAndSet applies are volatile.)


  * All memory actions by a thread must complete strictly before any
    effects of a subsequent invocation of Thread.start() by that thread.

  * All memory actions by a thread must complete strictly before
    termination of that thread.
JavaMemoryModel mailing list -

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