JDK-6507548 : REGRESSION: slower performance of GZIPInputStream for 5u10 (multi threaded testcase)
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 5.0u10
  • Priority: P2
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2006-12-22
  • Updated: 2010-07-29
  • Resolved: 2007-01-24
Related Reports
Relates :  
JDK-6206933 - GZipOutputStream/InputStream goes critical(calls JNI_Get*Critical) and causes slowness
Relates :  
JDK-6186200 - RFE: Stall allocation requests while heap is full and GC locker is held
Relates :  
JDK-6507183 - REGRESSION: slower performance of GZIPInputStream for 5u10 (single threaded testcase)
Relates :  
JDK-6348045 - REGRESSION: serious performance degradation as GZIPInputStream is slower
Description
5u6 is faster than 5u7 (resp. 5u10) if we compare the performance of the GZIPInputStream with a multi threaded testcase.

Customer claims that on his v880 and v890 servers (4 CPUs resp. 4 cores) the multi threaded testcase is faster on 5u6 than on any other later update release.

The problem is reproducible. The following tests has been made on a SunBlade 2000 (2 CPUs, 2 Threads) on Solaris/sparc. The testcase is a multi threaded version of the single threaded testcase from CR 6507183.

java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Server VM (build 1.5.0_06-b05, mixed mode)
time: 12863
time: 12877
time: 12763

java version "1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) Server VM (build 1.5.0_07-b03, mixed mode)
time: 16620
time: 16336
time: 15949

java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) Server VM (build 1.5.0_10-b03, mixed mode)
time: 16741
time: 16365
time: 16039

java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Server VM (build 1.6.0-b105, mixed mode)
time: 15408
time: 15605
time: 15746
Comments
EVALUATION This is not a defect, but an unfortunate consequence of needs to balance simple performance, such as a single thread using inflation and/or deflation, with many simultaneous threads using inflation/deflation and/or which consumes enough Java heap to require the services of the garbage collector. Changes have been made to zip code which allow the Java garbage collector to run where previously it was blocked from doing so for the duration of compression of user data; see the See Also bugs. The fix causes data to be copied to and from C buffers for compression (critical regions were used before). There is a cost to be paid in copying, which is what's apparent in releases since 1.5.0_06.
24-01-2007