performance impact of JNI GetCritical*

Michael Bien mbien at
Thu Mar 18 21:26:16 UTC 2010

On 03/18/2010 10:02 PM, Clemens Eisserer wrote:
>> If JNI CS
>> are very short-lived and infrequent and the arrays are as small as 12 bytes,
>> the difference would likely be negligible. As frequency of use (and degree
>> of concurrent use) and/or array size increases, NIO would likely become
>> increasingly better than JNI CS (in JDK 7 at least). At least that's my
>> hunch.
> I fear in the case of JOGL the problem is frequent JNI-CS with small arrays.
> So basically you do very little work per JNI-CS, thus the
> CS-enter/leave overhead is higher than with larger arrays. Best would
> probably to use NIO-Buffers directly, which would remove
> copy-overhead.
> - Clemens
sure thats what we doing - we force nio everywhere possible. But in some 
situations its to verbose for the host application.
e.g. JOCL is not all about big payloads. There are a lot of flags/small 
structs etc involved.

take a look at this method:,%20long,%20int,%20com.sun.gluegen.runtime.PointerBuffer,%20com.sun.gluegen.runtime.PointerBuffer,%20com.sun.gluegen.runtime.PointerBuffer,%20int,%20com.sun.gluegen.runtime.PointerBuffer,%20com.sun.gluegen.runtime.PointerBuffer%29

...lots of small buffers. (You find this kind of methods usually in 
inner loops)
The high-level api uses internal ThreadLocal buffers for those 
situations (and it works pretty well).

but thanks to everyone for answering - good discussion, I'll take a look 
at the NIO improvements.

Michael Bien

More information about the hotspot-gc-dev mailing list