JDK-6543126 : Level.known can leak memory
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.logging
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2007-04-05
  • Updated: 2017-12-08
  • Resolved: 2016-09-14
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 9
9 b137Fixed
Related Reports
Duplicate :  
JDK-6992761 - Memory leak in Level class via the "known" data variable
Relates :  
JDK-8187073 - The java.util.logging.Level.findLevel() will not correctly find a Level by it's int value
Relates :  
JDK-6274920 - JDK logger holds strong reference to java.util.logging.Logger instances
Description
See

http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java

for a description of the problem.
Comments
Patch under review http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/
29-07-2016
I agree with Jesse that the Level API usage pattern isn't well designed for subclassing. To lookup a known level instance, the name and value of the custom level instance are adequate. A factory method to create custom Level instances is one good solution; or another option is to cache a Level instance of the custom name/value instead of the subclass instance. Another observation to the Level API is that Level constructors initializes 3 final fields (name, value, resourceBundleName). However, Level.getName(), Level.getLocalizedName() and getResouorceBundleName() are not final and can be overridden. It's not obvious why not all Level instance methods are final and possibly an oversight. Unless there is a good reason to keep a reference to the Level subclass (I can't think of any), we should consider deprecating the Level class and define a new subclass to fix the memory leak and also address custom levels requirements/issues together.
12-12-2012
As java.util.logger belongs to corelib now, put it back to the pool.
16-10-2012
EVALUATION This is important bug which has to be fixed at least in the current release. Changing the implementation to use WeakReference's is relatively easy but most likely the fix would require a spec change, so a CCC request is going to be needed. Many thanks to Frank for describing the problem and to Jesse for filing this CR!
18-04-2007
SUGGESTED FIX Level.unknown should be a List<Reference<Level>> storing WeakReference's. Perhaps there should also be some factory method to create Level instances with particular labels and numeric values; subclassing an enumeration-like class such as Level is a highly suspect API usage pattern which should probably be deprecated.
05-04-2007