[concurrency-interest] question the about the JMM

Jaroslav Sevcik J.Sevcik at sms.ed.ac.uk
Mon Dec 10 06:14:56 EST 2007


Doug, we have already discussed this before, and I still maintain that 
the JMM is flawed with respect to transformations.

For example, the program

(initially x=y=0)
Thread1: r1=x; y=r1
Thread2: r2=y; x=(r2==1)?y:1;print r2

should never print 1 according to the JMM. However, an optimizing 
compiler can rewrite the second thread:

r2=y; x=(r2==1)?y:1;print r2 ==> r2=y; x=(r2==1)?r2:1; print r2 ==> 
r2=y; x=1; print r2 ==> x=1;print y

After this transformation, it's certainly possible to get 1 printed even 
on sequentially consistent hardware - just use the interleaving x=y=0; 
x=1; r1=x; y=r1; print y. Even Hotspot performs this transformation (see 
the attachment).

That said, I believe that Hotspot still satisfies the guarantee of 
sequential consistency for correctly synchronised programs, although it 
does not implement the JMM properly.

The lesson is still the same (and Jeremy should emphasize it more often) 
- synchronize properly and you'll be fine.

Jaroslav
 
Doug Lea wrote:
> 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?
>
> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Tester.java
Type: text/x-java
Size: 918 bytes
Desc: not available
Url : /pipermail/attachments/20071210/a66b63a9/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hotspot.log
Type: text/x-log
Size: 15403 bytes
Desc: not available
Url : /pipermail/attachments/20071210/a66b63a9/attachment-0001.bin 


More information about the Concurrency-interest mailing list