[concurrency-interest] a volatile bug?

Vitaly Davidovich vitalyd at gmail.com
Wed May 16 12:12:25 PDT 2012

It can be a compiler (mis)optimization that causes this, and not x86 memory

Someone posted the assembly output in the comments on SO and it does seem
like there's a place that loads 'b' from the stack rather than memory.
Hans' theory of CSE sounds plausible - can someone repro this without that
"int tt = b;" line?

Adding hotspot compiler guys in case they want to chime in.

Sent from my phone
On May 16, 2012 3:07 PM, "Aleksey Shipilev" <aleksey.shipilev at gmail.com>

> On Wed, May 16, 2012 at 10:40 PM, Boehm, Hans <hans.boehm at hp.com> wrote:
> > A JDK bug AND a serious test suite omission?
> Stress tests would probably JIT-compile the code in question. See below.
> > But is the problem real?  Can it be reproduced on a mainstream JVM?
> Same question.
> > Note that the example in the original posting also read b before the
> loop,
> > so naïve common subexpression elimination would cause the bug.  Hopefully
> > nobody does CSE in cases like this.
> FWIW, the test case in SO would probably not hit any compilation
> threshold in HotSpot, so it could be executed in interpreter. Then,
> assuming the interpreter does not reorder Java code, and assuming
> original SO poster runs Windows, and hence x86, and hence has TSO,
> this bug seems very unlikely. I would be surprised if it actually
> *can* be reproduced. That makes the whole story rather interesting.
> -Aleksey.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120516/251fcb51/attachment.html 

More information about the hotspot-compiler-dev mailing list