Folks -- I am in the final stages of revising a paper for journal
publication concerning a concurrent copying GC for Java. It has the
property that it disallows data races on NON-VOLATILE fields (and handles
volatile fields with a somewhat more complex and expensive technique). Here
is roughly what I say in the paper about this; I solicit your responses as
to its reasonableness, etc.:
- The "old" JMM (of the JLS and VM spec) leads to one of two undesirable
outcomes:
1) Systems that obey the orderings but are unacceptably slow because of
the optimizations that are inhibited and the memory fences required on
weakly-ordered machines, or
2) Systems that do not obey the spec, and encourage non-portable code,
which works under (say) a strongly ordered system or one without
certain aggressive optimizations, but can fail in other
circumstances.
- The "new" JMM (as in the Manson and Pugh document of 12/2001) has these
implications:
1) More efficient implementations, allowing certain desirable
optimizations, etc.,; and (importantly for our purpose)
2) Data races on non-volatile variables are not very useful, because
their ordering properties are so weak -- one can obtain older values
than simple-minded readings of code would lead one to expect, etc.
Now our algorithm admittedly makes the data race situation worse: if there
IS a race, it can potentially install a stale value in the new copy of a
copied object, with a write essentially being lost thereafter, but perhaps
transiently visible to some threads. This is anomalous, but assuming values
are not split, one will see only type-safe (though possibly stale)
values. (For OUR purposes, it wold be good if the new JMM actually allowed
this to happen, but I doubt the spec revision team will add it just for our
benefit :-).
We further argue that there are tools emerging that can detect data races,
which would allow one to add synchronization, or "volatile" declarations,
and thus avoid the problem. Finally, none of the benchmark code we ran had
ANY volatiles in it, so for some programming domains this is only a
theoretical problem.
Responses sooner rather than later will be more helpful, given deadlines
and all :-).
Regards -- Eliot
==============================================================================
J. Eliot B. Moss, Associate Professor http://www.cs.umass.edu/~moss www
Department of Computer Science +1-413-545-4206 voice
140 Governor's Drive, Room 372 +1-413-545-1249 fax
University of Massachusetts moss@cs.umass.edu email
Amherst, MA 01003-9264 USA +1-413-545-3733 Priscilla Coe sec'y
==============================================================================
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:37 EDT