How "evil" is GetPrimitiveArrayCritical?

[Clemens Eisserer]

Hello,

Thanks a lot for the detailed in-depth explanation :)

> Yes, it may potentially stall GC by as long as it might take the threads
> to release the critical section (although in all honesty, this could be
> dynamically improved). Basically, the way things work now is that once
> Eden fills up, and a JNI critical section is in use, further entries into
> the critical section are delayed -- thus there is not a danger of starvation
> or lock out. Thus, for example, in your case, GC
> may be delayed by as much as 2 ms. During this time, allocation requests
> may either go slow path (allocating out of the old generation), or in
> extreme cases, get stalled until the JNI CS releases.

So, to make it short - which implementation should I prefer?
The one which copies the data into a DirectByteBuffer or the
implementation which uses Get/ReleaseCritical and holds the lock until
it processes a small piece of data? (for max 2ms, but more likely
arround 500us).

Copying means two additional JNI call per stride, two
Get/ReleaseCritical pair which are held only short, and also managing
the native memory.
I benchmarked a bit and it seems both implementations perform almost
equally, however the code for the ByteBuffer-copying approach is more
complex and means a lot more offset/lenght management. The
OpenJDK-Corelibs guys seem a bit affraid of the Get/ReleaseCritical
approach, thats why I am nerving that much here ;)

Thanks a lot, lg Clemens