RFR: Access barriers for arraycopy

[Aleksey Shipilev]

On 02/20/2018 07:01 PM, Roman Kennke wrote:
>> *) 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... :/

> 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. Better to put comments around the shared
code mentioning this is a bugfix that needs to be upstreamed.

>> *) Stray whitespace before "((T*)":
>>
>>   87     src =  ((T*) (void*) src_obj) + src_offset;
>>
>>  103     src =  ((T*) (void*) src_obj) + src_offset;
> 
> Fixed.
> http://cr.openjdk.java.net/~rkennke/arraycopy-access-barriers/webrev.01/

OK, let's push it to sh/jdk10.

-Aleksey