Best practices to work on arrays via JNI from a few threads

[Sergey Bylokhov]

Hello, hotspot team.

I would like to clarify what is the current best practices to work with arrays from the JNI.

Currently I am working on the performance improvement in the color conversion area in the 
sun.java2d.cmm package. The logic there is simple pass the array of data(can be one pixel or huge 
image) to the native via JNI, then call some littlecms code(this is third party library) and save 
result back. For now that code uses GetByteArrayElements/ReleaseByteArrayElements. I have found that 
in some cases we spent most of the time(60%) copying data. So I have a few ideas on how to improve 
the code:
  - Use the GetPrimitiveArrayCritical/ReleasePrimitiveArrayCritical - it will increase the 
performance of the single threaded code, but may have some contention issue
  - Split the work across the threads

Do I understand correctly that I cannot use both improvements together?
The Critical API if not in the current implementation, but theoretically may return a copy of array, 
so if one thread will get a copy it will overwrite the whole array and delete the changes of the 
other threads.

Is my understanding correct that since there is no GetPrimitiveArrayRegionCritical API, I need to 
use GetByteArrayRegion/SetByteArrayRegion for each slice in each thread?

Probably we have some other way to do this job without coping the data fourth and back? Is it 
possible to create a view of the array and then lock only that slice via GetPrimitiveArrayCritical?

Or the Critical API became obsolete due to many issues described here?:
  * https://bugs.openjdk.java.net/browse/JDK-8199919?
  * http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052153.html

Thank you for any suggestions.

PS: I have read the long similar thread "GetPrimitiveArrayCritical vs GetByteArrayRegion":
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/051898.html
Where Martin suggested to add the "GetPrimitiveArrayRegionCritical", as far as understand we do not 
have such plans?

-- 
Best regards, Sergey.