Bug ID: 6751338 ZIP inflater/deflater performance

6751338 : ZIP inflater/deflater performance

Details

Type:	Bug	Submit Date:	2008-09-23
Status:	Closed	Updated Date:	2011-09-08
Project Name:	JDK	Resolved Date:	2011-04-27
Component:	core-libs	OS:	linux_ubuntu,windows_xp
Sub-Component:	java.util.jar	CPU:	x86
Priority:	P3
Resolution:	Fixed
Affected Versions:	1.4.2_10,7
Fixed Versions:	7

Related Reports

Backport:	JDK-2211252 - ZIP inflater/deflater performance
Backport:	JDK-2213859 - ZIP inflater/deflater performance
Backport:	JDK-2211963 - ZIP inflater/deflater performance
Backport:	JDK-2213885 - ZIP inflater/deflater performance
Duplicate:	JDK-7002855 - reading a .class resource from jar input stream does not work with jdk7 b116
Duplicate:	JDK-2200399 - Perf. of gzip in existing JDKs is too slower than in 1.3.1
Relates:	JDK-6206933 - GZipOutputStream/InputStream goes critical(calls JNI_Get*Critical) and causes slowness
Relates:	JDK-7095609 - TESTBUG: java/util/zip/TestDeflater.sh failure in 6u27-rev-b22
Relates:	JDK-6399199 - Improve performance of Deflater

Sub Tasks

Description

Dear all,

This is a snippet from the correspondence with SAP, who run into severe performance issues with JDK 1.4.2_10. No improvement has been observed with the recent release of JDK 1.4.2_18.
------------------------------------------------------------------------------------------------------
In our BI application we have massive performance problems
because of java.util.zip.Deflater and Inflater. A lot of customer
cases and also several escalations resulted from this.

The problem is similar to that described in SUN bugid 6364346
and can be simply reproduced with the attached test program.

Just call:   java -Xms1024M -Xmx1024M Bench test.htm

With 1.4.2_09 the performance is excellent, with later patch releases
it's horrible.

Following you see the results on my desktop PC:

C:\tmp\java\Deflater>\java\jdk1.4.2_09\bin\java -server -showversion
-Xms1024M -
Xmx1024M Bench test.htm
java version "1.4.2_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-b05)
Java HotSpot(TM) Server VM (build 1.4.2_09-b05, mixed mode)

Original length: 46932100 bytes
Deflated length: 2026929 bytes
Inflated length: 46932100 bytes

Duration of Deflate (in ms): 1390
Duration of Inflate (in ms): 3063

C:\tmp\java\Deflater>java -server -showversion -Xms1024M -Xmx1024M Bench
 test.ht
m
java version "1.4.2_18"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_18-b06)
Java HotSpot(TM) Server VM (build 1.4.2_18-b06, mixed mode)

Original length: 46932100 bytes
Deflated length: 2026929 bytes
Inflated length: 46932100 bytes

Duration of Deflate (in ms): 2602891
Duration of Inflate (in ms): 2421922

C:\tmp\java\Deflater>\java\jdk1.4.2_10\bin\java -server -showversion
-Xms1024M -
Xmx1024M Bench test.htm
java version "1.4.2_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03)
Java HotSpot(TM) Server VM (build 1.4.2_10-b03, mixed mode)

Original length: 46932100 bytes
Deflated length: 2026929 bytes
Inflated length: 46932100 bytes

Duration of Deflate (in ms): 8056797
Duration of Inflate (in ms): 7869140
------------------------------------------------------------------------------------------------------

I've included a test case provided by SAP to this report. Please handle this case with high 
priority because as mentioned above it has big impact at customer side.

Comments

EVALUATION This fix is basically to back out the fix for #6206933 we made back to jdk5, which is to use malloc+GetByteArrayuRegion to replace the original GetPrimitiveArrayCritical/ ReleasePrimitiveArrayCritical() pair when access the java byte array at native code Inflater/Deflater.c, to mainly workaround the GC/Critical... issue discussed in #6186200. The change for #6206933 itself has triggered lots of performance issues since its integration, some fixed, some still outstanding. The GC rfe#6186200 has been fixed long time ago, after couple weeks of discussion/debating, we all agreed that it's the time to back out#6206933. The corresponding wewbrev is at http://cr.openjdk.java.net/~sherman/6751338/webrev/
2011-05-20
EVALUATION The customer has confirmed that the workaround for 1.4.2 is working to their satisfcation.
2008-12-18
EVALUATION A workaround has been given to the customer that uses striding along the lines as to what we have in DeflatorOutputStream. This can be tuned to get performance very close to what we had when the implementation used JNI critical sections. In the background we will continue the analysis with a iew to coming up with a better solution that doesn't delay GC too much. Our plan is to let that solution bake in jdk7 for a few months before considering it for an update of a shipping release.
2008-10-25
WORK AROUND This issue can be worked around by using striding as is done in DeflaterOutputStream.
2008-10-08
EVALUATION Yes I tested this with 142_09 and 142_09 + fix for 6206933 The results show that this fix is causing the slowness. H:\Files\6751338>E:\ws\142\6751338\Output\bin\java -server -showversion -X ms1024M -Xmx1024M Bench test.htm java version "1.4.2_09-internal" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-internal-01) Java HotSpot(TM) Server VM (build 1.4.2_09-internal-01, mixed mode) Original length: 46932100 bytes Deflated length: 2026929 bytes Inflated length: 46932100 bytes Duration of Deflate (in ms): 2547 Duration of Inflate (in ms): 3860 After putting the fix for 6206933 H:\Files\6751338>E:\ws\142\6751338\Output\bin\javac Bench.java H:\Files\6751338>E:\ws\142\6751338\Output\bin\java -server -showversion -X ms1024M -Xmx1024M Bench test.htm java version "1.4.2_09-internal" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-internal-01) Java HotSpot(TM) Server VM (build 1.4.2_09-internal-01, mixed mode) Original length: 46932100 bytes Deflated length: 2026929 bytes Inflated length: 46932100 bytes Still running..... for a long time.
2008-09-25
EVALUATION Putting in hprof cpu times results for this on jdk 6 rank self accum count trace method 1 54.08% 54.08% 63343 301064 java.util.zip.Deflater.deflate 2 45.11% 99.20% 1466630 301094 java.util.zip.Inflater.inflate 3 0.36% 99.55% 1466630 301095 java.util.zip.Inflater.inflate 4 0.28% 99.83% 1 301130 Bench.inflate 5 0.10% 99.93% 1466629 301096 Bench.grow 6 0.02% 99.95% 1 301068 Bench.deflate 7 0.02% 99.97% 63343 301065 java.util.zip.Deflater.deflate 8 0.01% 99.99% 1 301036 java.io.FileInputStream.read Even cpu samples results show similar behaviour. Deflater.deflate and Inflater.inflate take most of the time.
2008-09-25
EVALUATION See 6206933.
2008-09-24

SELECT A COUNTRY/REGION
Africa Operation Argentina Australia Austria Bahrain Bangladesh Belgium & Luxembourg Belize Bhutan Bolivia Bosnia & Herzegovina Brasil Brunei Bulgaria Cambodia Canada - English Canada - French Chile China Colombia	Costa Rica Croatia Cyprus Czech Republic Denmark Ecuador Egypt Estonia Finland France Germany Greece Guatemala Honduras Hong Kong Hungary India Indonesia Iraq Ireland	Israel Italy Japan Jordan Kazakhstan Korea Kuwait Laos Latvia Lebanon Lithuania Malaysia Maldives Malta Mexico Moldova Nepal Netherlands New Zealand Nicaragua	Norway Oman Pakistan Panama Paraguay Peru Philippines Poland Portugal Puerto Rico Qatar Romania Russia Saudi Arabia Serbia & Montenegro Singapore Slovakia Slovenia South Africa Spain	Sri Lanka Sweden Switzerland -- French Switzerland -- German Taiwan Thailand Turkey Ukraine United Arab Emirates United Kingdom United States Uruguay Venezuela Vietnam Yemen

Hardware and Software, Engineered to Work Together