RFR: JDK-8198445: Access API for primitive/native arraycopy (original) (raw)

Erik Österlund erik.osterlund at oracle.com
Tue Mar 6 13:21:28 UTC 2018

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 ARRAYCOPYATOMIC decorator. If that comment is correct (I do not know if it is), then the ARRAYCOPYATOMIC 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/c1Runtime1.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::copyarray(), 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::XYZaddr() + 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

More information about the hotspot-gc-dev mailing list