RFR: JDK-8210187: Explicit barriers for C2

[Roman Kennke]

> Hi Alexey,
> 
>> On 30 Aug 2018, at 19:02, Aleksey Shipilev <shade at redhat.com> wrote:
>>
>> On 08/30/2018 05:58 PM, Roman Kennke wrote:
>>>>> From a far away interface design perspective, those are still heap
>>>> accesses and GCs might be interested in intercepting e.g. final values.
>>>> Maybe keep the resolves there and augment them with something like
>>>> ACCESS_FINAL and/or ACCESS_STABLE and let the backend decide what to do
>>>> with it? For example, in Shenandoah we have an option to optimize for
>>>> the final/stable stuff and exploit the UD in the JMM in our favour, or
>>>> to be conservative in favour of crazy applications, that could react on
>>>> such a decorator. WDYT?
>>>>
>>> If final and stable properties can be exploited by the GC, then 
>>> annotating that explicitly with decorators makes sense to me. However, 
>>> it seems more intuitive to me to make such annotations in the relevant 
>>> accesses, and not in a resolve barrier. Or what do you think?
>>
>> I think we need barriers by default, because we don't know what GC would do. There is no knowledge
>> that it is safe to read the backing String arrays on this level. I agree that additional decorator
>> tags about the nature of access may help GC to decide what to do with it. That feels like a good
>> follow-up, which requires introducing resolve barriers anyway.
> 
> I suppose that is true, despite it being a bit weird that we are cluttering the code with barrier hooks that 0 GCs (Shenandoah included) require. I suppose I am okay with that though.

For the various reasons we listed in this thread, we are not completely
convinced that 'Shenandoah does not need it'. At the very least,
Shenandoah will use it and emit barriers in those places. And
performance-wise it doesn't hurt.

>> I think current placement is beneficial, because otherwise we need to put barriers into the each of
>> platform-specific assemblers that expand the relevant String intrinsic nodes. Which appears more
>> tedious, and it makes barriers opaque for high-level optimizations, e.g. folding the consecutive GC
>> barriers. (This seems to be the reason to have BarrierSetC2 to begin with!)
> 
> Yeah I don’t think we want to go down that route either.
> 
> Looks good. Ship it!

Aleksey, Erik: thanks for reviewing!

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180830/985b0e2b/signature.asc>