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

[Roman Kennke]

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