[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    How "evil" is GetPrimitiveArrayCritical?
From:       ramon.garcia.f+java () gmail ! com (=?UTF-8?Q?Ram=C3=B3n_Garc=C3=ADa?=)
Date:       2007-12-31 23:15:37
Message-ID: daa40b5d0712311515t585ea3f8t627acba050eeadd4 () mail ! gmail ! com
[Download RAW message or body]

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
>


[prev in list] [next in list] [prev in thread] [next in thread]