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

[David Holmes]

On 6/03/2018 10:54 PM, Erik Österlund wrote:
> Hi David,
> 
> It is atomic with the ARRAYCOPY_ATOMIC decorator. If that comment is 
> correct (I do not know if it is), then the ARRAYCOPY_ATOMIC decorator 
> should probably be used here.

If that code implements a Java array copy then yes it is required to be 
32-bit atomic. Do you need the decorator to get 32-bit atomicity?

David

> Thanks,
> /Erik
> 
> On 2018-03-06 13:48, 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?
>>
>> 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
>>>
>