How "evil" is GetPrimitiveArrayCritical?

Ramón García ramon.garcia.f+java at
Mon Dec 31 15:15:37 PST 2007

Y Srinivas Ramakrishna, you said that the the CMS is not a moving GC,
so GetPrimitiveArrayCritical does not block garbage collection. If I
understand well, the functions GetXXXArrayElements
(XXX=Boolean,Short,Chart,...) should not perform a copy of the
elements when a non moving garbage collector is used. But, from the
implementation (hotspot/src/share/vm/prims/jni.cpp, macro
jni_Get##Result##ArrayElements) this is not the case: a copy is always
made. Is this the logical behaviour? If not, would a contribution
changing this behaviour be accepted (not making a copy if the
collector is not a moving collector)?


On Dec 31, 2007 11:58 AM, Clemens Eisserer <linuxhippy at> wrote:
> 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

More information about the hotspot-runtime-dev mailing list