GetPrimitiveArrayCritical vs GetByteArrayRegion: 140x slow-down using -Xcheck:jni and java.util.zip.DeflaterOutputStream
xueming.shen at oracle.com
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 hotspot-dev