[concurrency-interest] a volatile bug?
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
> > 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.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev