[concurrency-interest] question the about the JMM
dl at cs.oswego.edu
Sat Dec 8 08:59:09 EST 2007
A couple of thoughts on this discussion. Maybe they'd be
better on JMM list, but I think membership overlaps a lot.
Even though the JMM stands alone, regardless of underlying
caches, fences, and other memory system control, many people
seem to want a way to reconcile what they know about memory
systems with the JMM. Some of these people know less about
memory systems than is required to understand how they do
fit together. In which case, suggesting they ignore memory
system control and focus on JMM rules is good advice.
But some do know enough, and know what they want in terms
of memory control, but don't know how to achieve it in Java code.
So there ought to be a good high-level account of the JMM
targeted to such people. In addition to mapping reads
and writes of final, volatile, plain fields to fences
etc (as in my http://gee.cs.oswego.edu/dl/jmm/cookbook.html),
this mainly revolves around how/why optimization via program
analysis adds to the straight mapping story.
For example, that if a compiler sees
"local a = x.field; local b = x.field;" that it is normally
allowed (but not required) to transform to: "local a = x.field;
local b = a;". Or maybe kill "b" entirely and just use "a".
Or maybe not even actually perform the x.field read at all
if its value is known for all possible sequential executions
(in which case it need not even actually write it).
And so on. Plus the fun/weird causal cycle issues such
analyses can encounter. Is there a simple way to characterize
these to arrive at a good short answer to questions from
this sort of audience?
More information about the Concurrency-interest