ClassLoader leak in MethodHandle.asType()

John Rose john.r.rose at oracle.com
Fri Apr 24 21:06:59 UTC 2015


Good point.  Are you seeing a leak in practice?
The cache is important, especially to inexact MH.invoke.
— John

On Apr 24, 2015, at 9:14 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> I think there is a Class(Loader) leak in MethodHandle.asType() implementation. If for example some MH (say mhX) is long lived (because it is a system cached MH) and a client "generates" variants from it by invoking mhX.asType(newType) and the newType contains a type (either return type or parameter type) that is loaded by some child ClassLoader, then such derived MH is retained strongly from mhX via the MethodHandle.asTypeCache field. Until this field is overwriten by some other MH, child ClassLoader can not be GCed.
> 
> In case this one-element cache is needed to speed things up, it should be a WeakReference, like the following:
> 
> http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/webrev.01/ <http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/webrev.01/>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20150424/dd90e71f/attachment.html>


More information about the mlvm-dev mailing list