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

Erik Österlund erik.osterlund at oracle.com
Mon Aug 20 13:25:02 UTC 2018


Hi Roman,

Now I get what you mean. Yes, your solution seems much less intrusive. 
Looks good.

Thanks,
/Erik

On 2018-08-20 15:07, Roman Kennke wrote:
> 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




More information about the hotspot-gc-dev mailing list