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

[Xueming Shen]

On 03/05/2018 10:28 AM, Xueming Shen wrote:
> On 03/05/2018 08:34 AM, Ian Rogers wrote:
>> Firstly, we're not running -Xcheck:jni in production code :-) During
>> development and testing it doesn't seem an unreasonable flag to enable, but
>> a 140x regression is too much to get developers to swallow.
>>
>> There are 2 performance considerations:
>> 1) the performance of -Xcheck:jni, which probably shouldn't be orders of
>> magnitude worse than without the flag.
>> 2) the problems associated with JNI criticals, for which GetByteArrayRegion
>> is a panacea but by introducing a copying overhead.
>>
>>
>
> The reason the GetByteArrayCritical was/is being used here is exactly to avoid the copy
> overhead, which was an issue escalated in the past. Though the "copy overhead" appears
> to be much bigger for the GBAC when -Xcheck:jni is used here.
>
> Another issue with the DeflaterOutputStream is the default buf size is relative too small,
> for historical reason. So with a DeflaterOutStream(deflated, new Deflater(), 8192 *64),
> is which a bigger buf/8192*64,  the performance is close to the run with the -Xcheck:jni
>

type:

in which a bigger buf/8192*64 is used, .... run without the -Xcheck:jni is specified.

-Sherman