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

Sergey Bylokhov bylokhov at amazon.com
Fri Oct 8 01:15:21 UTC 2021


On 10/7/21 5:01 PM, David Holmes wrote:
>> The final parameter to GetPrimitiveArrayCritical is "jboolean *isCopy",
>> so you can pass the address of a variable there and know whether you
>> have a copy or not, and then decide how to proceed from there. Hotspot
>> will not make a copy but will use either object-pinning (for GC's that
>> do that - only Shenandoah) or the GCLocker. Deferring GC may cause you
>> other problems so you have to evaluate how long you will need to process
>> the array data in the worst case. You can process the raw array in
>> multiple threads, but then you need to synchronize those threads to know
>> when the array can be released again.
> 
> I was thinking of a model where one thread calls
> GetPrimitiveArrayCritical, verifies it has a non-copy, and then shares
> it with other threads. You could of course have each thread call
> GetPrimitiveArrayCritical and just work on its own region of the array,
> but if you wanted to guard against a theoretical VM that might return a
> copy then the fallback code would be much more complicated.

But how I can share it to some other java threads if it is not possible
to call java methods after GetPrimitiveArrayCritical?

The other way to implement it is to call GetPrimitiveArrayCritical
and then use the native threads. But I really would like to use java
thread pool.

-- 
Best regards, Sergey.


More information about the hotspot-dev mailing list