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.