RFR: 8217576: C1 atomic access handlers use incorrect decorators

[Erik Osterlund]

Hi Kim,

Looks good.

Thanks,
/Erik

> On 12 Mar 2019, at 02:09, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 12/03/2019 4:37 am, Kim Barrett wrote:
>>> On Mar 11, 2019, at 3:22 AM, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Hi Kim,
>>> 
>>>> On 10/03/2019 7:47 am, Kim Barrett wrote:
>>>> Please review this fix of decorator defaulting in C1 atomic access
>>>> generators.  As noted in the bug, C1 presently ignores the decorators
>>>> and only generates fully barriered operations, so the incorrect
>>>> decorators haven't been affecting code generation.
>>> 
>>> So by fixing this and potentially using weaker memory ordering we could infact expose hitherto hidden bugs. :) Okay.
>> It's weirder than that.  The old code produces a decorator set that is
>> either empty in the MO_ field, or contains two set bits in that
>> field. Neither of those is valid, so who knows what would happen with
>> later changes elsewhere.  My guess: either an assertion failure (good)
>> or quietly ignoring an intentional request for a weaker barrier (not
>> so good, might lead to some real head-scratching debugging).
> 
> That sounds like we have missing assertions if exactly one-bit must always be set in the decorator!
> 
> Though putting in a stronger MO than necessary would never be a functional bug. I'd be more concerned if the empty field led to an unexpected relaxed MO - that could be a real head-scratcher.
> 
> David
> -----
> 
>>> The fix itself looks good.
>> Thanks.
>>> Thanks,
>>> David
>>> -----
>>> 
>>>> CR:
>>>> https://bugs.openjdk.java.net/browse/JDK-8217576
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~kbarrett/8217576/open.00/
>>>> Testing:
>>>> mach5 tier1.