-
Bug
-
Resolution: Fixed
-
P3
-
7
-
generic
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8019018 | 7u45 | John Rose | P3 | Closed | Fixed | b01 |
JDK-8003096 | 7u40 | John Rose | P3 | Closed | Fixed | b01 |
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.
- backported by
-
JDK-8003096 MethodType leaks memory due to interning
- Closed
-
JDK-8003097 MethodType leaks memory due to interning
- Closed
-
JDK-8019018 MethodType leaks memory due to interning
- Closed
- relates to
-
JDK-8000999 backport of JSR 292 to 7u
- Closed