RFR: JDK-8198445: Access API for primitive/native arraycopy

[Per Liden]

On 03/06/2018 01:48 PM, David Holmes wrote:
> Hi Roman,
> 
> Not a review as I'm not familiar enough with the Access API, but in 
> src/hotspot/share/c1/c1_Runtime1.cpp the comments above the changed code 
> need updating - probably deleting. I assume the Access API arraycopy is 
> atomic?

Agree. We should understand of that comment is correct, and if so use 
the ARRAYCOPY_ATOMIC decorator, i.e. 
HeapAccess<ARRAYCOPY_ATOMIC>::arraycopy().

/Per

> 
> Thanks,
> David
> 
> On 6/03/2018 9:56 PM, Roman Kennke wrote:
>> Currently, the Access API is only used for oop-arraycopy, but not for
>> primitive arraycopy. GCs might want to intercept this too, e.g. resolve
>> src and dst arrays.
>>
>> There *is* an implementation of primitive arraycopy in the Access API,
>> but it doesn't even compile, because Raw::arraycopy() does not take src
>> and dst oop operands, but it's called like that. The only reason why
>> this does not blow up (I think) is that because nobody calls it, the
>> compiler doesn't even get there.
>>
>> This change fixes the Access API/impl and adds the relevant calls into
>> it (in C1 and runtime land). C2 uses arraycopy stubs (which cannot be
>> handled here) or calls out to the ArrayKlass::copy_array(), which should
>> be covered with this change.
>>
>> It should be possible to use the same Access API for Java-array <->
>> native-array bulk transfers, which currently use the rather ugly
>> typeArrayOop::XYZ_addr() + memcpy() pattern. I'll address that in a
>> separate change though.
>>
>> http://cr.openjdk.java.net/~rkennke/8198445/webrev.00/
>>
>> Tests: tier1 ok
>>
>> Please review!
>> Thanks, Roman
>>