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