-
Bug
-
Resolution: Fixed
-
P3
-
6u2, 6u10, 6u18
-
b109
-
generic, x86
-
generic, linux_2.6, windows_vista
-
Not verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8164878 | OpenJDK6 | Andrew Hughes | P3 | Resolved | Fixed | b40 |
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.
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.
- backported by
-
JDK-8164878 java.util.jar.Pack200.Packer Memory Leak
- Resolved
- duplicates
-
JDK-6927240 Memory leak in pack200 implementation
- Closed
-
JDK-6545954 pack200 impl does not allow releasing its data
- Closed
- relates to
-
JDK-8164555 pack200: Leave ZipFile open on exceptions
- Resolved