question regarding call sites and garbage collection

[Jochen Theodorou]

Because of my mistake Charles made the next one and replied only to me, 
wehre as I think he wanted to reply to the list as well. So I attach 
that mail below my answer in full.

Am 17.03.2011 17:04, schrieb Charles Oliver Nutter:
[...]
> For us, the cached object is just a tuple of an int and a
> DynamicMethod object, with the latter being the exact same thing
> stored in the metaclass method table. So other than the hard reference
> back to the class (via DynamicMethod), there's only a two-field object
> created for the cache. Barely shows up in memory profiles.
>
> I'm still surprised you felt it necessary to make the cache soft
> referenced. Is it primarily because of large structures created for
> caching, or do Groovy programs generate lots of transient classes at
> runtime?

actually I am unable to remember the discussion in any detail. Actually 
maybe the information is outdated by now. I guess I should run some tests ;)

One part though is that a call site might reference a meta class and a 
meta class on the other hand references a lot of bigger objects. But I 
wonder... maybe it would be better to softrefernce the meta class there 
instead of the array. Same for call sites based on MetaMethods.

>> 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?
>
> I would imagine (but do not know) that class unloading triggers jitted
> code to be reevaluated or thrown away. Hopefully John can explain
> what's happening here.

For that too happen the class must be known to be collectable... I was 
wondering if inlining maybe prevents that from happening all together.

>> 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...
>
> You mean an indy call site, yes? Yeah I'm not sure how this will work
> either, but in theory an indy call site should still be an object on
> the heap. Whether you can see what it references, though, I'm not
> sure. Try it and see?

actually I mean any call site, since I have to set a target and the 
target is a MethodHandle and through that I get class hard referenced.


bye Jochen



Am 17.03.2011 17:04, schrieb Charles Oliver Nutter:
> On Thu, Mar 17, 2011 at 1:23 AM, Jochen Theodorou<blackdrag at gmx.org>  wrote:
>> 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.
>
> You didn't find that traversing the SoftReference for every call
> introduced unacceptable overhead? I experimented with making JRuby's
> call sites weakly reference the cached method, but it always added
> overhead. It also seemed to be only rarely useful, since most systems
> reach a steady state where they're not loading a lot of new code, and
> for short-lived code (eval) we use the interpreter.
>
> For us, the cached object is just a tuple of an int and a
> DynamicMethod object, with the latter being the exact same thing
> stored in the metaclass method table. So other than the hard reference
> back to the class (via DynamicMethod), there's only a two-field object
> created for the cache. Barely shows up in memory profiles.
>
> I'm still surprised you felt it necessary to make the cache soft
> referenced. Is it primarily because of large structures created for
> caching, or do Groovy programs generate lots of transient classes at
> runtime?
>
>> 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?
>
> I would imagine (but do not know) that class unloading triggers jitted
> code to be reevaluated or thrown away. Hopefully John can explain
> what's happening here.
>
>> 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...
>
> You mean an indy call site, yes? Yeah I'm not sure how this will work
> either, but in theory an indy call site should still be an object on
> the heap. Whether you can see what it references, though, I'm not
> sure. Try it and see?
>
> - Charlie


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