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

[Roman Kennke]

The problem with the prologue stuff is that we do not get to see the
actual oops+offsets there, but only the computed addresses. Plus they
are also used by C2 (iirc), and there we deal with arraycopy some way up
in the ideal graph which is more efficient. As I said, we could put that
in C1 LIR, but this is very cumbersome because of required use of fixed
registers.

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
>