How "evil" is GetPrimitiveArrayCritical?

[Y Srinivas Ramakrishna]

Good point! Yes, that appears a very reasonable change (when it's the case that
the target is in the old generation collected by the CMS collector).

thanks!
-- ramki

----- Original Message -----
From: Ramón García <ramon.garcia.f+java at gmail.com>
Date: Monday, December 31, 2007 3:16 pm
Subject: Re: How "evil" is GetPrimitiveArrayCritical?
To: hotspot-runtime-dev at openjdk.java.net


> 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)?
> 
> Ramon
> 
> 
> On Dec 31, 2007 11:58 AM, Clemens Eisserer <linuxhippy at gmail.com> 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
> >