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

Xueming Shen xueming.shen at
Mon Mar 5 18:28:48 UTC 2018

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
for the byte[1 << 23] input.

Understood the test case is to show the issue for the GetPrimitiveArrayCritical+check:jni
use scenario.


More information about the core-libs-dev mailing list