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

[Xueming Shen]

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.

-Sherman

> Moving this code to pure Java would be awesome! Could we start a
> bug/process?
>
> Thanks,
> Ian
>
>
> On Mon, Mar 5, 2018 at 12:42 AM Alan Bateman<Alan.Bateman at oracle.com>
> wrote:
>
>>
>> On 05/03/2018 06:33, David Holmes wrote:
>>> <swapped jdk-dev for core-libs-dev>
>>>
>>> Hi Ian,
>>>
>>> Do you run with -Xcheck:jni in production mode because you load
>>> unknown native code libraries? It's mainly intended as a diagnostic
>>> option to turn on if you encounter a possible JNI problem.
>> It does unusual to be running with -Xcheck:jni in a performance critical
>> environment. I would expect to see-Xcheck:jni when developing or
>> maintaining a library that uses JNI and drop the option the code has
>> been fulling tested.
>>
>> Lots of good work was done in JDK 9 to replace the ZipFile
>> implementation with a Java implementation and it would be good to get
>> some results with a re-write of Inflater and Deflater. It would need
>> lots of testing, including startup. We would need have a dependency on
>> libz of course as it is needed by the VM to deflate entries in the
>> jimage container (when they are compressed) or access JAR files on the
>> boot class path.
>>
>> -Alan
>>