GetPrimitiveArrayCritical vs GetByteArrayRegion: 140x slow-down using -Xcheck:jni and

Xueming Shen xueming.shen at
Mon Mar 5 20:54:31 UTC 2018

On 3/5/18, 12:45 PM, Xueming Shen wrote:
> On 3/5/18, 11:15 AM, Ian Rogers wrote:
>> Thanks! Changing the DeflaterOutputStream buffer size to be something 
>> other than the default reduces the number of JNI native calls and is 
>> a possible work around here, as this is an implementation detail 
>> could it be made in the JDK? Unfortunately larger input sizes will 
>> also regress the issue as the number of calls is "input size / buffer 
>> size". The JNI critical may give direct access to the array but 
>> depending on the GC, may require a lock and so lock contention may be 
>> a significant issue with the code and contribute to tail latencies. 
>> In my original post I mention this is difficult to measure and I 
>> think good practice is to avoid JNI critical regions.
> We do have a history on the usage of 
> GetPrimitiveArrayCritical/Elements() here regarding the
> potential "lock contention", copy overhead... and went back and forth 
> on which jni call is the
> appropriate one to go. Martin might still have the memory of that :-)
And for the record. The direct root trigger of this issue probably is 
the fix for JDK-6311046 that went into jdk9.



More information about the core-libs-dev mailing list