RFR: 8224187 Refactor arraycopy_prologue to allow ZGC read barriers on arraycopy

Per Liden per.liden at oracle.com
Tue May 21 08:36:25 UTC 2019


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



More information about the hotspot-gc-dev mailing list