JDK-6374637 : Transient excess memory consumption in NIO-based classloading path
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2006-01-19
  • Updated: 2017-07-20
  • Resolved: 2017-07-20
Related Reports
Relates :  
JDK-6373059 - OutOfMemoryError on ZipFile.open
Description
The new NIO-based fast path for class loading introduced as a
performance optimization in 1.5 has introduced a problem where the
ZipInputStream associated with the ByteBuffer is not closed eagerly.
In the original code path, where the class's bytes are read into a
byte[] before being handed to the JVM for processing, the InputStream
is closed eagerly. This means that finalization is being used to
reclaim the ZipInputStream which leads to excess C heap consumption
before the ZipInputeStream and associated Inflater objects are
collected. A new entry point needs to be added to sun.misc.Resource to
be called from java.net.URLClassLoader in order to eagerly close the
ZipInputStream.

This issue was discovered during investigation of an escalation from
Nortel. The fix is in the process of being tested and if testing is
successful then this should be considered a showstopper for 5.0 update
7.
Comments
Little or not interest, or activity, on this issue recently. Closing
20-07-2017
EVALUATION Decommitted from 5.0u8 and lowered the priority as this has been proven not to be the root cause of a recent customer escalation.
14-06-2006
EVALUATION A new sun.misc.Resource.close() API is needed which will be called from the URLClassLoader when the code path associated with defining the class from a ByteBuffer is used.
19-01-2006