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

[Roman Kennke]

Thanks for reviewing!

BTW, I'll remove IN_HEAP from this patch too, similar to what you
suggested for JDK-8209667. The final patch that I'm going to push
(unless you object) will be this:

http://cr.openjdk.java.net/~rkennke/JDK-8209668/webrev.01/

Pushed to submit-repo for testing now.

Cheers,
Roman


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