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

[Ian Rogers]

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.

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
>