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

[Roman Kennke]

Makes me wonder: why attempt to be smart in c1_Runtime1.cpp, when we can
just as well call typeArrayOop::copy_array() and have it do the right
thing? Or go even further and also do it for oop-arraycopy?

Roman

> 
> 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
>>>>>
>>>
>