JavaMemoryModel: Volatile variables in a weak memory model

From: Bill Pugh (
Date: Sat Jul 17 1999 - 11:33:54 EDT

Discussing for the moment what a weak memory model might look like:

If Foo.x is declared as a volatile field, then you are declaring that
you intend to have a data race on it. In that case,

         Initially Foo.x = "bar";

Thread 1 Thread 2
Foo.x = "foo"; char c = Foo.x.charAt(1);

should result in c being 'a' or 'o', never a null pointer exception
or other error. This isn't required in the old memory model, but it
clearly makes sense and I think should be supported in any new memory

The strong way of doing this would be to require a W-W memory barrier
immediately before a write into a volatile reference, and a R-R
memory barrier immediately after a read of a volatile reference. We
might want to narrow the memory barriers, so that the R-R memory
barrier only orders reads of fields of the reference (probably closed
transitively, so that Foo.x.y.z is guaranteed not to be stale).

Furthermore, if you are reading a volatile field, it seems pretty
clear that you don't want that value to be stale. So perhaps we
should also require that you cannot reorder a read of a reference,
and a read of a volatile field from that reference.

Note that on many memory models, including Sparc RMO, the read
barriers could be removed.

Furthermore, for efficiency, we could allow you to declare volatile
final fields. These would have the volatile semantics above, but
would also have final semantics: once you had loaded the field (and
gotten a non-stale value), you would know it couldn't change, so you
could keep it in a register even though it was marked as volatile.

The current compiler rejects any attempt to mark a field as both
final and volatile, but that would be a fairly small change in the

With these changes, if you declared all of the fields of an object to
be final and volatile, you would be guaranteed non-stale access, and
yet you wouldn't be stuck with doing expensive memory operations to
get the value of the fields. You would essentially get the strong
memory model for that object.

For example, I believe that making all of the fields of
java.lang.String be "final volatile" would fix the problems we've
been talking about for Strings.

This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.

To send a message to the list, email
To send a request to the list, email and put
your request in the body of the message (use the request "help" for help).
For more information, visit

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