GetPrimitiveArrayCritical vs GetByteArrayRegion: 140x slow-down using -Xcheck:jni and java.util.zip.DeflaterOutputStream

[Xueming Shen]

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.

https://bugs.openjdk.java.net/browse/JDK-6311046

-Sherman

>
>
>