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

[Erik Österlund]

Hi David,

The ARRAYCOPY_ATOMIC decorator makes the arraycopy atomic over the size 
of the passed in elements.
In this case, it looks like the address has been type erased to void*, 
and hence lost what the element size was. There is currently no overload 
accepted for type erased element - only accurate elements {jbyte, 
jshort, jint, jlong}.

So it looks like an overload must be added to accept type erased void* 
elements and make that call conjoint_memory_atomic when the 
ARRAYCOPY_ATOMIC decorator is passed in.

Thanks,
/Erik

On 2018-03-06 13:56, David Holmes wrote:
> 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
>>>>
>>