JDK-6206933 : GZipOutputStream/InputStream goes critical(calls JNI_Get*Critical) and causes slowness
  • Type: Bug
  • Status: Resolved
  • Resolution: Fixed
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Priority: P2
  • Affected Version: 1.4.2_06
  • OS: solaris_8
  • CPU: sparc
  • Submit Date: 2004-12-10
  • Updated Date: 2011-02-21
  • Resolved Date: 2005-09-02
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 Availabitlity Release.

To download the current JDK release, click here.
Other JDK 6
1.4.2_10 b02Resolved 6Resolved
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
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

Comments
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
2005-01-03

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
2004-12-10

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
2004-12-10