JDK-6386530 : Memory leak in sun.misc.CacheEntry
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 8.1ur1,6u7
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_9,solaris_10
  • CPU: sparc
  • Submitted: 2006-02-16
  • Updated: 2011-02-16
  • Resolved: 2009-10-06
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 6
6-poolResolved
Related Reports
Duplicate :  
JDK-4918870 - Examine session cache implementation (sun.misc.Cache)
Description
This bug has been raised after CPRE Engineering has fixed the memory leak in bug 6382063.
While testing the FVB from bug 6382063, a second memory leak has been observed. 

Running OptimizeIT against the test case from bug 6382063 , suggested memory still leak 
not restricting to the following classes 

eg 
sun.misc.CacheEntry
com.sun.net.ssl.internal.ssl.SSLSessionlmpl.com.sun.net.ssl.internal.ssl.SSLSessionimpl()
java.lang.ThreadLocal$ThreadLocalMap$Entry
Comments
EVALUATION Adding evaluation done by ###@###.###: The situation where the leak occurs is something like this: . JSSE adds an SSLSessionImpl to cache. Cache allocates CacheEntry and Ref (SoftReference) to SSLSessionImpl. . GC occurs, clears the SoftReference'd SSLSessionImpl. The CacheEntry and Ref are still referenced by Cache, therefore not released by GC. . SSLSessionContextImpl.adjustCacheSize() cannot release the CacheEntry object either. It iterates via cache.elements(), which returns only valid entries, not ones where the SoftReference has already been cleared. . Cache.rehash() removes cleared CacheEntry objects, but that does not avoid unbounded growth either because it doubles the number of entries each time. Bottom line is that there is a problem in sun.misc.Cache that causes a memory leak. However, I don't think this issue is particularly critical. The memory usage of the leaked entries is relatively small (maybe 100 bytes including all objects and VM overhead), so in many situations this would not cause a problem. As for a fix, either sun.misc.Cache should to be fixed (preferably by using a ReferenceQueue), or JSSE should use a different cache implementation (we also have sun.security.util.Cache and sun.misc.SoftCache, which should work better than sun.misc.Cache). We should carefully look at the options to see which one minimizes the risk for an update release. ###@###.###.
20-06-2006