JDK-7118277 : MappedMXBeanType.convertedTypes abuses WeakHashMap
  • Type: Bug
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: linux
  • CPU: x86
  • Submitted: 2011-12-05
  • Updated: 2013-09-19
  • Resolved: 2013-09-19
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.
Related Reports
Relates :  
The "Leaking WeakHashMap" canned analysis in the NetBeans Profiler, applied to a heap dump made of the NB IDE, turned up (among other violations):

MappedMXBeanType.convertedTypes: java.util.WeakHashMap#103 is wrong: key java.lang.Class#10232 is reachable from value sun.management.MappedMXBeanType$CompositeDataMXBeanType#1

Indeed, MappedMXBeanType.convertedTypes is a WeakHashMap, yet all of the possible value types refer strongly (in fact directly, field 'javaType') to the key type (Class). Since the map is static, if getMappedType is ever called on a class loaded by some user ClassLoader, that loader (including all of its classes and their static fields) will never be collectible.

The class MappedMXBeanType sits in the package sun.management, it is used only for the platform MXBeans, and all types saved in its map are from the rt.jar, and the types will not be removed from a VM, so no memory leak problem here. By the way, here using WeakHashMap is unnecessary, I will create a bug to use simple HashMap instead of WeakHashMap, mainly for performance.

SUGGESTED FIX Get rid of the cache entirely, or make the value type be SoftReference<MappedMXBeanType> and accept occasional recreation.