performance impact of JNI GetCritical*

[Y. Srinivas Ramakrishna]

Hi Clemens. Michael --

On 03/18/10 11:18, Michael Bien wrote:
> Thanks for the answer Clemens,
> 
> comments inline...
> 
> On 03/18/2010 06:20 PM, Clemens Eisserer wrote:
>> Hi Michael,
>>
>>    
>>> How optimized are the Get/ReleasePrimitiveArrayCritical JNI functions?
>>> Do they disable GC or do they only pin the array at the specific address?
>>>      
>> For moving gc's they actually stop the whole GC process as long as all
>> arrays are released by ReleasePrimitiveArrayCritical.
>> So basically the cost is some thread-synchronization (to make the gc
>> know on all threads not to run now), plus the impact on the GC. So for
>> small arrays theres quite high overhead.
>> CMS itself is non-moving (old gen) so basically there could be some
>> optimizations, but no idea wether this is actually done.

CMS GC is indeed permitted even when in JNI critical sections, but
since most objects are allocated in Eden which uses copying
collection, the performance effect of long-lived JNI CS can
indeed be disastrous even when you are using CMS. In fact,
it might be worse in a configuration using CMS because
when Eden is full and because of a long-lived JNI CS we do
not scavenge, allocations happen from the old gen, and
as we know allocation out of CMS' free lists can be much
slower (although of course, we can theoretically withstand
much-longer-lived CS because CMS GC can concurrently collect
the garbage produced from these allocations). Bottom line:
CMS does not give you any practical performance advantage
wrt the over(ab?)use of JNI CS.

>>
>>    
>>> lets say I have a short java array of length 12. Should I copy it to a
>>> direct NIO buffer and use the buffer as vehicle, use Get/ReleaseCritical
>>> or something else?
>>>      
>> For very short arrays this is quite likely beneficial (at least if
>> you're on JDK7, at least older JDK6 releases do get/releasecritical +
>> memcpy in jni code).

Right; this is a fact that I learnt much to my delight recently.
I requested that this improvement be backported to JDK 6, but
I do not know if/when that might happen.

-- ramki

>>
>> Just to be curious, whats your actual usecase?
>>    
> the usecase was to optimize the generated code of JOGL 2 / JOAL / JOCL 
> etc. for some corner cases.
> I feared that putting load on GetCritical* could cause GC-dependent 
> problems. Thats why I am already using ThreadLocal direct NIO buffers in 
> the high-level API of JOCL to prevent this situation.
> 
> - michael
> 
> 
>> - Clemens
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>
>>
>>    
> 

_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use