RFR: JDK-8221848: Shenandoah: ArrayCopy post-barrier improvements

[Zhengyu Gu]

Looks good.

-Zhengyu

On 4/3/19 12:41 PM, Roman Kennke wrote:
> Just like the arraycopy pre-barrier, the arraycopy post-barrier should 
> check for count == 0 and UPDATEREFS gc-state in the generated stubs to 
> avoid calling into the runtime at all in those cases. The runtime can 
> then elide checking this.
> 
> Why is this relevant? Because calling into runtime involves storing and 
> restoring *all registers* around the call. That would be 32 (x86) or 64 
> (aarch64) memory accesses to do nothing at all (outside 
> update-refs-phase or when dealing with empty arraycopy).
> 
> This change proposes to slightly change the meaning of the UPDATEREFS 
> state: so far it would only be active during the dedicated update-refs 
> phase after evacuation. Updating-references while marking would not have 
> this flag. However, arraycopy is the only place where we use this flag 
> at all, and we use it to determine if current GC phase is actually 
> updating references. I suggest to also activate it during marking (when 
> updating references) and traversal (always also updating references). 
> Then we can make the check in assembly very simple.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8221848
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8221848/webrev.00/
> 
> Testing: hotspot_gc_shenandoah (x86_64 and aarch64)
> 
> Ok?
> 
> Roman