Bug ID: JDK-6280693 Mmap the whole jar files takes too much perceived footprint

JDK-6280693 : Mmap the whole jar files takes too much perceived footprint

Type: Bug
Component: core-libs
Sub-Component: java.util.jar
Affected Version: 1.4.0,5.0u17,6

Priority: P3
Status: Resolved
Resolution: Fixed
OS: linux,solaris,solaris_10
CPU: generic,x86,sparc

Submitted: 2005-06-06
Updated: 2011-06-14
Resolved: 2005-07-22

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	Other	Other	JDK 6
5.0u29-revFixed	5.0u30-revFixed	5.0u31Fixed	6 b45Fixed

Related Reports

Duplicate :	JDK-4705373 - new java.util.zip.ZipFile causes OutOfMemoryError for large zip files
Duplicate :	JDK-6830986 - JRE 5.0 quickly receives OutOfMemoryError in ZipFile.open
Relates :	JDK-6713913 - Fatal errors during jar file processing
Relates :	JDK-6304463 - zip file IO operations on Solaris fail if thread is interrupted
Relates :	JDK-6507118 - REGRESSION: Testcase from CR 6348045 runs much slower on Java SE 6 than on J2SE 5
Relates :	JDK-6533291 - Work around 32-bit Solaris stdio limit of 256 open files
Relates :	JDK-6332094 - "jar t" and "jar x" should use ZipFile, not ZipInputStream
Relates :	JDK-6283665 - 3% "creep" in footprint3_real on Solaris
Relates :	JDK-6305549 - JCK-runtime-6.0_b04: api/java_util/concurrent/Executors/index.html#Executors failed, mustang
Relates :	JDK-6308841 - nsk/stress/jni/jnistress005 fails with strange message
Relates :	JDK-6725672 - Two open file handles for every jar in jdk6, but one in jdk 1.5

Description

Currently all the jar/zip files are mmaped to the address space of java application. Customers are complaining about the huge perceived footprints. One way to workaround this is to mmap part of the jar file or read it from disk.

Expriments show this could reduce percieved footprint by more than 100% on Solaris and more than 30% on Linux since rt.jar just takes too much space.
###@###.### 2005-06-06 06:48:39 GMT

Comments

EVALUATION The main reason of huge perceived footprint is because on Solaris, when you mmap a big file such as rt.jar (around 40MB), it actually shows it on "ps -ef" or "pmap -x". The solution is to read most of the jar files while still mmaping the mostly common accessed part of jar file which is central directory. Expriments show that by doing this, we could achieve both decent startup and footprint performance improvement. The webrev is at http://javaweb.sfbay.sun.com/~xl116366/webrev/fread ###@###.### 2005-07-19 03:08:57 GMT ###@###.### 2005-07-20 01:03:11 GMT

19-07-2005