RFR: JDK-8209668: Explicit barriers for C1/assembler

[Erik Österlund]

Hi Roman,

Do I understand this right that you do not want to perform the resolve 
barriers in the arraycopy prologue in the stub generator, and instead 
want to put it in the C1 code that calls the arraycopy stub? I'm not 
sure how I feel about that. But I suppose I am okay with that, but would 
be even happier if the stub generator could deal with this in the 
prologue. Are we hunting registers for the write barrier in the 
arraycopy stubs? I thought there were a whole bunch of them we could use 
in the prologue. Maybe I missed something.

/Erik

On 2018-08-19 20:34, 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 (this
> time the assembly part).
>
> The places are based on a few years of Shenandoah development experience
> and are:
> - arraycopy
> - locking
>
> While we could handle those in LIR too (we did that for some time), it
> is *much* more cumbersome because, for example, arraycopy uses fixed
> registers.
>
> The barriers are created via the existing BarrierSetAssembler API.
>
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8209668/webrev.00/
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8209668
>
> Testing: hotspot/tier1 locally
>
> Can I please get a review?
> Thank you,
> Roman