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

[Erik Österlund]

Hi Roman,

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

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.

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

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