question regarding call sites and garbage collection

Jochen Theodorou blackdrag at gmx.org
Thu Mar 17 01:24:16 PDT 2011


Am 16.03.2011 20:06, schrieb Charles Oliver Nutter:
> On Wed, Mar 16, 2011 at 3:36 AM, Jochen Theodorou<blackdrag at gmx.org>  wrote:
>> The result, should I have understood correctly, will be, that each
>> scriptn will cause the former scriptn (lastScript) to be referenced in a
>> way that prefents that from being garbage collected, even though scriptn
>> does not reference lastScript directly and there will be no reference to
>> the class loader as well. So in theory the last script could be garbage
>> collected but the MethodHandles prevent that from happening.
>
> You understand correctly. But presumably your existing call site
> caching has this same side effect, yes? Or is your call site cache
> weak referenced?

I think it is SoftReference, but yes, our call site caching array can be 
collected. Our MetaMethods are not exactly small structures and 
reference many other meta structures, so a call site can be quite heavy 
in our case (even if multiple call sites share most objects). Therefore 
them being collectable was a requirement. Now for Methodhandles I would 
expect that the meta structures are a lot less memory consuming so maybe 
the problem is much smaller... but that the static data of the classes 
will stay makes me a little bit worried I must say.

On the other hand... how does inlined code for normal Java behave? I 
assume that the JVM will too add some checks and will keep references to 
the classes internally somehow. Does normal inlining in Java also mean 
that the class cannot be collected?

And finally... I would assume that most memory profilers out there have 
no possibility to visualize that Class X cannot be collected because 
Class Y references it in a call site. That makes debugging memory 
problems a much bigger task. Not that it is an easy one right now...

bye Jochen

-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org



More information about the mlvm-dev mailing list