some thoughts on ClassValue

John Rose john.r.rose at oracle.com
Sat Apr 27 14:54:23 PDT 2013


On Apr 27, 2013, at 2:34 PM, Jochen Theodorou <blackdrag at gmx.org> wrote:

> Am 27.04.2013 23:26, schrieb John Rose:
> ...
>> Each instance of the Groovy runtime will use a distinct ClassValue instance.
>> 
>> If the ClassValue instance goes dead, then all the values (for each
>> class) bound using that instance should go dead also.
>> 
>> If they don't it's a bug.
> 
> well... I assume that if I have a ClassValue for Object that is an 
> isntance of Foo, that this instance will stay as long as I don't delete 
> it myself. That is how ClassValue works, or not? And that is exactly my 
> problem too.

As a simple example:  Make a ClassValue object, bind a 1Mb array to Object.class using it, and then throw it all away.  (Except Object.class, naturally.)  Even if you do this in a loop, you should not get a storage leak.

(A class value bound to a class is live only if both the Class and the ClassValue instance are both live.)

Often people bind ClassValue instances to "static final" variables.  If the class containing the static variable goes away, then the ClassValue goes away, and anything bound (to whatever class, including Object) should go away.  That's nice, at least in theory.

Things get tricky (this probably happens in practice) when there is a loop:

  class MyRuntimeInMyClassLoader { static final MyClassValue MYCV = ... } => instance of MYCV
  instance of MYCV x Object.class (say) => instance of MyMetaStuff
  instance of MyMetaStuff => MyRuntimeInMyClassLoader.class

Although I am not one of the 12 people on the planet who fully understand class loader interactions with GC, I suspect this loop might be "sticky", and might have to be broken by (say) a SoftReference.  (You can use a SoftReference if you are willing to have the GC break references not recently used, which you can reconstruct if needed.)

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130427/f7203385/attachment.html 


More information about the mlvm-dev mailing list