RFR: JDK-8210187: Explicit barriers for C2

[Aleksey Shipilev]

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20180830/796d5ca3/signature.asc>