RFR (M): 8000805: JMM issue: short loads are non-atomic

[Aleksey Shipilev]

In fact, I've been hit by the infamous trouble that RuntimeMXBean had
munched -client, and forked JVM was running in server mode nevertheless.
Running with -f false works. Sorry for false alarm.

-Aleksey.

On 10/20/2012 02:09 AM, Vladimir Ivanov wrote:
> Aleksey,
> 
> Thanks for checking that. I'll look into the issue.
> 
> Best regards,
> Vladimir Ivanov
> 
> On 10/20/12 1:46 AM, Aleksey Shipilev wrote:
>> Please double-check. Reproduces perfectly with 32-bit build on my x86_64
>> Linux:
>>
>> $ ~/Install.32/jdk7u4/bin/java -client -version
>> java version "1.7.0_04"
>> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
>> Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode)
>>
>> $ ~/Install.32/jdk7u4/bin/java -client -jar
>> target/concurrency-torture.jar  -t ".*ShortAtomicity.*"
>> Java Concurrency Torture Tests
>> ---------------------------------------------------------------------------------
>>
>> Running in forked mode...
>>
>> Running
>> net.shipilev.concurrent.torture.tests.primitiveAtomicity.ShortAtomicityTest
>>
>> Warmup .....
>>                       Observed state  Occurrences          Expectation
>> Interpretation
>>                              [0, 0]  (    878998)             REQUIRED
>>                             [-1, -1] (  10025286)             REQUIRED
>>                             [-1, 0]  (     15596)            FORBIDDEN
>>
>> Running
>> net.shipilev.concurrent.torture.tests.primitiveAtomicity.VolatileShortAtomicityTest
>>
>> Warmup .....
>>                       Observed state  Occurrences          Expectation
>> Interpretation
>>                               [0, 0] (   5322930)             REQUIRED
>>                             [-1, -1] (   1774531)             REQUIRED
>>                              [-1, 0] (     13709)            FORBIDDEN
>>
>>
>> -Aleksey.
>>
>>
>> On 10/20/2012 12:37 AM, Vladimir Ivanov wrote:
>>> Disregard my comment about C1.
>>>
>>> I vaguely remember I saw it fails and CR has a comment by Vladimir K.
>>> about C1 being also affected, but I'm not able to reproduce the problem
>>> anymore.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 10/19/12 10:39 PM, Vladimir Ivanov wrote:
>>>> http://cr.openjdk.java.net/~vlivanov/8000805/webrev.00/
>>>> 282 lines changed: 255 ins; 27 del; 0 mod
>>>>
>>>> Ideal transformations during parsing & IGVN may rematerialize loads in
>>>> order to reify useful information (like signed/unsigned load). Such
>>>> behavior breaks JMM - instead of a single atomic load, multiple loads
>>>> are performed violating consistency of loaded data.
>>>>
>>>> The fix is to disable such transformations at all, but perform relevant
>>>> optimizations during matching.
>>>>
>>>> It fixes only C2 part of problem. С1 has similar deficiency, but it'll
>>>> be addressed separately.
>>>>
>>>> Testing: failing test, test for new matching rules, JPRT, CTW (x86, x64
>>>> & sparc).
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>