JDK-6888127 : java.util.jar.Pack200.Packer Memory Leak
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 6u2,6u10,6u18
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux_2.6,windows_vista
  • CPU: generic,x86
  • Submitted: 2009-10-05
  • Updated: 2016-08-26
  • Resolved: 2011-05-17
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.
JDK 7 Other
7 b109Fixed OpenJDK6Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Description
FULL PRODUCT VERSION :
java 1.6  all versions

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows Vista Business Edition

A DESCRIPTION OF THE PROBLEM :
When you use the Pack200 API from within a Java Program the memory consumed to pack a jar file is never freed.

The reason is that com.sun.java.util.jar.pack.ConstantPool caches all values in static Hashmaps. When the compression process is finished the maps stay filled and there is no way to get rid of their content.

This is not critical for a short running packer program but we have an application server that builds .pack.gz install bundles dynamically and suffers from this problem. The ConstantPool gets hughe and consumes all available memory.

The cache must be per Packer instance and not static.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
  From a java progrma pack200 a big jar file . The memory is never freed.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
After packing finishes the memory of the cache should get freed.
ACTUAL -
The memory is not garbage colleted and there is no way to clear the cache manually.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Start the packing in a new forked java process.

Comments
EVALUATION Right the static HashMaps in the ConstantPool is the culprit, need to make it so, such that the GC will be effective.
22-06-2010