RFR: Access barriers for arraycopy

[Roman Kennke]

>>> *) Since we are stabilizing sh/jdk*10*, I would prefer not to extend Access API here: when doing
>>> this, we are risking unforeseen interactions with the rest of VM and other GCs. Do we actually need
>>> the extensions to work correctly?
>>
>> If we don't want that in 10, they we should get the shenandoah/jdk
>> into shape ASAP, because this is work that's important to get
>> Shenandoah in shape for upstreaming ;-)
>
> Yeah, but not before we stabilize sh/jdk10... :/

What is the criteria for that?
The way I see it is that we could move unstable-ish development to
shenandoah/jdk and only backport relevant stabilizing stuff back to
shenandoah/jdk10. There'll always be stuff going on that potentially
unstabilizes shenandoah/jdk10 as long as it's our main dev branch
(e.g. traversal GC stuff, GC interface related stuff, etc). And some
of it is actually important (GC interface).

>> It's not an extension of the Access API per se. It#s more like a bug
>> fix. There's a call to Raw::arraycopy() that plain simply wrong: that
>> call does not accept oop arguments. Since it was never used in
>> upstream yet, the compiler never resolved and complains about that. I
>> would like to get it into Shenandoah first to give it some exposure
>> and testing, then bring it upstream as soon as possible. No, it
>> doesn't not work/make sense without those shared code changes.
>
> OK. So it is still required in sh/jdk10 for correctness.

No, not really. The code is correct as it is. Right now we have put
the barriers around the callsites to arraycopy/memcpy calling code.
This change moves into a proper location in the Access API under GC
specific directory. Overall it reduces upstream exposure (assuming the
required shared code changes go upstream, which I assume they will).

> Better to put comments around the shared
> code mentioning this is a bugfix that needs to be upstreamed.

Added those comments:
https://paste.fedoraproject.org/paste/xiBFWZ8-3aBxxChl1fQCRA
Full webrev:
http://cr.openjdk.java.net/~rkennke/arraycopy-access-barriers/webrev.02/

Ok now?

I also filed an upstream bug for it:
https://bugs.openjdk.java.net/browse/JDK-8198445

Roman