RFR: JDK-8210187: Explicit barriers for C2

[Erik Osterlund]

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.

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

Thanks,
/Erik

> 
>>>>>> Bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8210187
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8210187/webrev.00/
> 
> This looks good to me.
> 
> -Aleksey
>