JDK-7127687 : MethodType leaks memory due to interning
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-01-06
  • Updated: 2013-10-20
  • Resolved: 2013-10-20
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.
7u40Fixed 8Fixed
Related Reports
Relates :  
MethodType objects are interned and unique MethodType object is maintained for a specific combination of parameter types and return type. This is done by interning MethodType objects using a static final HashMap called "internTable" in MethodType class. This leads to Class objects being leaked. If user code creates a MethodType object using any user-defined Class, then the corresponding MethodType ends up stored in this HashMap and so user's class is prevented from being GC'ed. All classes loaded by defining loader of such class and all reachable objects from static fields of such classes are also kept alive. The only workaround now is to avoid creating MethodTypes with any user defined Class object. This workaround implies we can create MethodHandles on virtual methods of user's classes. This is because "this" type of such methods will be user defined Class and so that will be leaked into JDK's internTable.

This was fixed awhile back: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/78f1f4e4e9c7

respective test vm/mlvm/meth/func/regression/b7127687

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/78f1f4e4e9c7

EVALUATION Correct. Suggested fix is reasonable.

WORK AROUND Do not use MethodTypes involving non-bootstrap types. But such a workaround is harsh and limits design options.

SUGGESTED FIX We could intern MethodTypes involving only bootstrap types. For other MethodTypes, we could always use .equals to compare rather than identity comparison. Or we could maintain non-bootstrap MethodTypes by a weak hash set.