How "evil" is GetPrimitiveArrayCritical?

Y Srinivas Ramakrishna Y.S.Ramakrishna at Sun.COM
Tue Jan 1 11:19:50 PST 2008


By the way ...

> > or lock out. Thus, for example, in your case, GC
> > may be delayed by as much as 2 ms. During this time, allocation requests

... that is true assuming single-threaded calls to the CS's, but of course,
as you noted, this approach does not scale as one increases the number of
such threads or the size of the array chunk that you process during
a JNI/CS.

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

Honestly, i am not sure, but  perhaps someone else on this (or the
core libraries) list may have direct experience.

> 
> Copying means two additional JNI call per stride, two
> Get/ReleaseCritical pair which are held only short, and also managing
> the native memory.

The best approach might be (if that is possible, avoiding the copying and
keeping all data in the direct byte buffer during its entire tenure). That
avoids the critical section entirely and makes the solution more
scalable, i guess.

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

If you have only a few threads which each process relatively small
chunks of the buffer in each JNI/CS, then you should stick with
the Get/ReleaseCritical approach and avoid then copying entirely.

If on the other hand you expect to have lots of threads and expect
lots of concurrency, then i'd go for a direct byte buffer approach
but avoid copying (or at least amortize the cost of any copying over
much larger and heavyweight processing of the copied buffer).

In the end it's a trade-off, and it's true that Get/ReleaseCritrical on
the one hand as well as copying on the other will both be inhibitors
to scaling. On the third hand, direct byte buffer management itself
is, as you stated, extra work and messy.

Sorry, the above is more armchair theorization than borne out of
any direct experience with either approach so i will defer to those
with (recent, post-6186200) experience with both. (Re 6186200,
see also http://bugs.sun.com/view_bug.do?bug_id=6539517 whose
fix has not yet been committed, and which closes a hole in 6186200.)

over and out.
-- ramki



More information about the hotspot-runtime-dev mailing list