RFR: JDK-8231499: Shenandoah: compiler/arraycopy/TestDefaultMethodArrayCloneDeoptC2 fails

[Roman Kennke]

Here comes a better approach.

Instead of doing one call into runtime, and then check heapstable there, 
then maybe do a call to the clone-barrier, and then do another 
unconditional call to the copy-routine there, let's do this instead:

1. check heap-stable in compiled code, and call to runtime clone-barrier 
only when heap is unstable
2. runtime clone-barrier *only* fixes the src object. it does not 
actually copy anything
3. unconditionally call into the usual optimized copy routine from 
compiled code; that only copies the payload without touching headers

I think this is the best approach so far:
- It keeps the fast-path slim (heapstable-check + fast-copy)
- Copying is optimized and only touches the absolute minimum of memory 
(important for small object clones)


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

Testing: I've thrown a whole bunch of tests at it:
- hotspot_gc_shenandoah (x86_64, x86_32)
- the failing test from the bugreport
- a full successful run of specjvm with fastdebug and 
+AbortVMOnCompilationFailure

Can I please get a review?

Thanks,
Roman


> Recent arraycopy changes breaks compilation of C2 arraycopy intrinsic. 
> It fails silently, so you only notice degradation of performance.
> 
> Apparently the register allocator barfs on the 4 arguments (I suppose 
> sending both the address and the base of that address is a little bit 
> funny).
> 
> Fix is to fall back to what Aleksey original proposed and only send src 
> and dst object base pointer, and let runtime figure out the rest.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8231499
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8231499/webrev.00/
> 
> Testing: hotspot_gc_shenandoah (x86_64 and x86_32) and testcase that is 
> provided in the bug report, all pass.
> 
> Ok?
> 
> Roman