This note is from Gao and myself. Gao is a professor at U. Delaware,
working on multithreading execution models and architectures
(www.capsl.udel.edu). I'm at the IBM T.J. Watson Research Center,
working on the Jalapeno JVM for SMP servers (www.research.ibm.com/jalapeno).
We have been working on the specification of memory models that do not
rely on memory coherence. One such model that we proposed in 1993 is
called Location Consistency (LC). (See www.capsl.udel.edu/LC.shtml
> Bill Pugh <firstname.lastname@example.org> on 07/09/99 11:01:55 AM
> So I think we can declare that the existing JMM is dead, and that it
> will need to be replaced, not patched.
Wonderful! Since the JMM is to be replaced from scratch, we would
like to discuss a fundamental question:
Should memory coherence be part of the new JMM?
1) We agree with the "lower bound" goal proposed by Sarita Adve:
> Sarita Adve <email@example.com> on 6/30/99 06:05:23 PM
> *** Data-race-free programs should be guaranteed sequentially consistent
> results. (Whether a program is data-race-free should be determined by its
> behavior on a sequentially consistent machine.) This is a bound on how weak
> the model can be.
It is interesting to note that memory coherence is NOT necessary to
achieve this lower bound. If the program itself is data-race-free,
then all writes to the same location will be totally ordered by
synchronizations, even if the underlying memory model does not enforce
coherence. In other words, removing memory coherence is not in
conflict with the lower bound goal.
2) We also agree with the "upper bound" goal:
> *** The new specification should not impose "excessive" ordering
> on current hardware. This means that any constraints not necessary to
> SC for data-race-free programs should be imposed with "care and
> deliberation." This is a bound on how strong the model can be.
From 1), it's clear that memory coherence is a constraint not
necessary to ensure SC for data-race-free programs. As in Bill Pugh's
Java Grande '99 paper, we've argued in the past that memory coherence
imposes excessive ordering constraints, which can prevent many
compiler/software and processor/hardware optimizations (e.g.,
reordering of potentially aliased load instructions). Therefore,
memory coherence appears to be in conflict with the upper bound goal.
3) From 1) and 2), our proposal is to get rid of the memory coherence
assumption in the new JMM!
Bill reported the usual concerns with removing memory coherence:
> * Some people said "Not having that would be like not guaranteeing
> that reads/writes of integers are atomic. How can you even think of
> _not_ making that safety guarantee?"
> Another interesting comment is a confirmation of something I've heard
> from a number of other people: that all Sparc systems run under TSO
> (Total store order); far too much of Sun's software breaks if you use
> a more relaxed memory model.
We understand these concerns. Note that the proposal for removing
memory coherence is only for the Java language and the JMM. Legacy
operating systems and other applications written in native code are
still free to retain memory coherence. Even if current processors
enforce TSO, removing coherence from the new JMM will enable many more
compiler optimizations to be performed on Java programs. In addition,
the new JMM will be prepared for future processors that do not enforce TSO.
If we are willing to accept the removal of memory coherence from the
new JMM, the next question that arises is: what guarantees should be
made for programs with data races? We believe that the LC model
offers one answer. Are there any other suggestions?
Gao and Vivek
P.S. -- This note is on the memory coherence aspect of the JMM. There
has been a lot of good discussion on other aspects of the JMM, such as
object initialization. We believe that removing memory coherence from
the JMM will not limit proposals on other aspects of the JMM.
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, NY 10598
URL FOR JALAPEŅO PROJECT: http://www.research.ibm.com/jalapeno
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email firstname.lastname@example.org and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:17 EDT