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

[Vladimir Ivanov]

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
>