RFR: 8217576: C1 atomic access handlers use incorrect decorators

[David Holmes]

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.
> 
>