RFR: JDK-8209667: Explicit barriers for C1/LIR

[Roman Kennke]

Hi Erik,

thanks for reviewing!

> Looks good in general. A few minor things though:
> 
> 1) I think IN_HEAP should be removed from the access_resolve callsites
> (because IN_HEAP is for differentiating if an access hits inside or
> outside of the heap, and this is seemingly orthogonal).

Good point. Fixed.

> 2) I see you used the LIRAccess object to wrap the context of the
> resolution. However, in this case since this is not an access, this
> seems to cause more trouble than it solves. The only parameters that
> apply is the address (which could be represented with a LIROpr), and the
> decorators. So I think I would just pass those two parameters around in
> the BarrierSetC1 backend, instead of passing around the baked LIRAccess
> object with dummy parameters.

We also need the LIRGenerator* and CodeEmitInfo* (see below). Would you
prefer to pass 4 arguments around? I am ok with either approach, and
passing for args is probably easier to understand than passing one
opaque LIRAccess&. Whatever you prefer.

> 3) What do you need the CodeEmitInfo parameter for? It doesn't seem to
> be used anywhere. Or is it?

I believe we use it in case the obj is not known to be not NULL, in
which case we need to emit null-checks.

I'll post an updated webrev once we agree on #2.

Roman


> Thanks,
> /Erik
> 
> On 2018-08-19 20:20, Roman Kennke wrote:
>> I am x-posting this to hotspot-gc-dev and hotspot-compiler-dev because
>> it touches both.
>>
>> In order to support GCs like Shenandoah, we need some explicit read- or
>> write-barriers in a few places. We already introduced them in the
>> runtime and interpreter, this change intends to do the same for C1 (at
>> least the LIR part, will followup with a few C1/assembly ones soon).
>>
>> The places are based on a few years of Shenandoah development experience
>> and are:
>> - CRC32 intrinsics
>> - vectorizedMismatch intrinsic
>> - NIOCheckIndex instrinc
>>
>> The barriers are created via the BarrierSetC1 API, which is a no-op by
>> default. Similar to what we did with interpreter, it allows to pass
>> ACCESS_READ and/or ACCESS_WRITE to it to indicate the required strength
>> of the barrier. Also, similar to what we did in interpreter, this
>> defaults to ACCESS_READ|ACCESS_WRITE if no such strength indicator is
>> passed, i.e. the maximum strength.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8209667/webrev.00/
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8209667
>>
>> Testing: hotspot/tier1 locally
>>
>> Can I please get a review?
>> Thank you,
>> Roman
>