[aarch64-port-dev ] RFR: 8224187 Refactor arraycopy_prologue to allow ZGC read barriers on arraycopy

[Roman Kennke]

Well, I disagree. But it's not important enough to hold anything back,
so please go ahead.

Roman


> Hi Roman,
> 
> I have to agree. This is not a about adding a band-aid for ZGC, it's
> about fixing aarch64's barrier set.
> 
> I don't think this should be conflated with the other patch you
> proposed, since that's is a different review/discussion to solve a
> different problem.
> 
> cheers,
> Per
> 
> On 2019-05-20 17:53, Erik Österlund wrote:
>> Hi Roman,
>>
>> I don't think I would call it a band-aid for ZGC to add the src
>> parameter to the prologue. That is just harmonizing the arraycopy
>> interface model we already have on all platforms today, to do on
>> AArch64 what the other platforms have always been doing since the API
>> was introduced, since before ZGC was integrated.
>> However, having the actual copying being performed sometimes inside of
>> the public pre-barrier, which may or may not throw a checkcast
>> exception, seems like a very different beast to jam into the public
>> interface.
>> Apart from being a rather ugly abstraction, I don't feel like I can
>> assess if that approach is correct or not (w.r.t. checkcast
>> exceptions) without seeing the proposed shenandoah code that uses it.
>> In your patch I just see passing around of values that are never used.
>> I also don't know how that will play with windows that has an
>> ABI-adapter from windows ABI to Sys-V used to wrap the arraycopy code.
>> The ABI wrapper saves windows callee saved registers on the thread,
>> assuming that the copying code itself does not nest... I don't know if
>> it still does not nest with this approach, as the ABI conversion scope
>> is set up outside the barrier set calls, and inside of the prebarrier
>> in the runtime that calls arraycopy back into the stub code again, I
>> think the result on windows is that it might overwrite the callee
>> saved registers in a nasty and intermittent way that is hard to
>> reproduce.
>>
>> /Erik
>>
>> On 2019-05-20 12:40, Roman Kennke wrote:
>>> I'd rather see Erik's proposal implemented to make the GC generate the
>>> whole path to begin with. Otherwise we'd band-aid for ZGC now, and later
>>> have to band-aid again for Shenandoah. See discussion for JDK-8223240
>>> and in your aarch64 on ZGC thread.
>>>
>>> Roman
>>>
>>>> Hello,
>>>>     On aarch64 the signature for
>>>> barrierSetAssembler::arraycopy_prologue needs to be changed in order
>>>> accept the source as well as the destination array for ZGC's barriers.
>>>>
>>>> The bug:
>>>>   https://bugs.openjdk.java.net/browse/JDK-8224187
>>>> and the patch:
>>>>    http://cr.openjdk.java.net/~smonteith/8224187/webrev.0/
>>>>
>>>>
>>>> BR,
>>>>     Stuart
>>>>
>>