Bug ID: JDK-6206933 GZipOutputStream/InputStream goes critical(calls JNI

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other	JDK 6
1.4.2_10 b02Fixed	6Fixed

Application shows slowdown when transferring data after compressing.

thread dump & pstack shows lot of threads churning around JNI_Get*Critical methods which are attributing to the slowness.

It seems GZIP class methods are going critical which causes the slowness.
###@###.### 2004-12-10 05:34:16 GMT

EVALUATION I am not a JNI expert, but it seems from reading http://java.sun.com/docs/books/performance/1st_edition/html/JPNativeCode.fm.html that the *Critical functions should only be used when the data is used for a very short time, and the operations being performed in the critical regions are too slow (compressing/decompressing/checksumming) and cause slowdowns in multi-threaded programs. I suspect the submitter is correct, and most of the calls to JNI_*Critical should be replaced with the non-Critical versions of same. ###@###.### 2005-1-03 22:26:29 GMT

03-01-2005

SUGGESTED FIX One approach for this can be to use direct java.nio.ByteBuffer's instead of using JNI_GetArrayPrimitiveCritical from GZIP methods. ###@###.### 2004-12-10 05:34:17 GMT ---------------------------------------------------------- A binary with the following changes is being tested by HSBC and so far we have received positive feedback. http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=1470 ###@###.### 2005-05-20 05:51:11 GMT

10-12-2004

WORK AROUND Customer provided workaround: Use CBZip2{InputStream, OutputStream} from the apache ant project instead of GZIP compression ###@###.### 2004-12-10 05:34:17 GMT

10-12-2004

Relates :	JDK-6507548 - REGRESSION: slower performance of GZIPInputStream for 5u10 (multi threaded testcase)
Relates :	JDK-6975829 - Perf. of gzip in existing JDKs is too slower than in 1.3.1
Relates :	JDK-6399199 - Improve performance of Deflater
Relates :	JDK-5043044 - GZIPOutputStream doesn't scale on 4way Windows systems
Relates :	JDK-6356456 - REGRESSION: GZIPInputStream is slower on 1.4.2_10 than on 1.4.2_09
Relates :	JDK-6348045 - REGRESSION: serious performance degradation as GZIPInputStream is slower
Relates :	JDK-6438254 - Very slow performance from GZIPInputStream in JDK 1.5.0_07-b03
Relates :	JDK-6751338 - ZIP inflater/deflater performance
Relates :	JDK-6623164 - severe performance issues with JDK GZIP classes and object serialization
Relates :	JDK-2132422 - REGRESSION: serious performance degradation as GZIPInputStream is slower
Relates :	JDK-5072161 - OutOfMemoryError while using GZIPOutputStream
Relates :	JDK-6507183 - REGRESSION: slower performance of GZIPInputStream for 5u10 (single threaded testcase)