On 02/11/2014 09:46 PM, Martin Buchholz wrote: > On Mon, Feb 10, 2014 at 3:43 PM, Mike Duigou <[email protected]> wrote: > >> On Feb 10 2014, at 04:33 , Doug Lea <[email protected]> wrote: >> >>> Among the constraints on solution is that several of these >>> methods compile down to no-ops on many common platforms. >> >> This is interpreted as a benefit. However, if the are no-ops only for the >> most common platform (x86) then we are likely to see a rough path for other >> platforms. Incorrect or inconsistent usage of these methods in user code >> will, instead of having no effect, result in unexpected and possibly >> mysterious runtime failures on other platforms. > > We already have the problem that programs that succeed on x86 may fail on > other platforms with a weaker memory model. > > The JVM has been pretty good about hiding these differences thus far. It >> would be nice to see a "least common denominator" non-no-op mode as part of >> the VM implementation that provided the opportunity to test in the most >> pessimistic conditions. > > If you wanted to be able enable robust testing, create an adversarial VM > implementation (e.g. via hotspot flag) that did maximal compiler > reordering, e.g. between synchronization points write values to main memory > in reverse order. But that's a big job that's probably not going to happen?
Valgrind has a race checker that can be used for this kind of thing, and it can probably be utilized for Java. I wouldn't be surprised if we found some races in HotSpot. Andrew.
