question regarding call sites and garbage collection

[Jochen Theodorou]

Am 17.03.2011 19:39, schrieb Charles Oliver Nutter:
> On Thu, Mar 17, 2011 at 10:39 AM, Jochen Theodorou<blackdrag at gmx.org>  wrote:
[...]
> I would also be worried, but less so, about the numbers of
> SoftReferences and whether they'd impact GC. A typical app will have
> thousands of call sites, after all.

I think I did not really present that correctly. In Groovy we have a 
SoftReferenced CallSiteArray instance. This contains the call sites of 
the whole class. That means there is only 1 SoftReference per class. 
Also to reduce the cost of that indirection the array is loaded only 
once per method. So the more call sites are in a method the less weight 
does the indirection have.

>> 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.
>
> Yes, it also occurred to me that you may have a lot more data
> generated in service of the call site. In JRuby there's only two
> things needed there...a serial number to invalidate it, and a
> reference to the method bound at a given name. Since there's no
> multidispatch for Ruby to Ruby calls, the caching is pretty light.
>
> For Ruby to Java calls, we do have to manage multidispatch tables much
> like I'm sure you do. But we don't bother aging them out or
> weak/soft-referencing them.

Well, Groovy can run with a pretty low memory profile thanks to that. It 
does have all advantages and disadvantages.

>> For that to happen the class must be known to be collectable... I was
>> wondering if inlining maybe prevents that from happening all together.
>
> What I mean is that the JVM could easily keep a listing of inlined
> bodies that reference a given class, and when that class changes or is
> unloaded it would mark those bodes "not entrant" so they won't be
> encountered again.
>
> Of course we can figure this out pretty easily; I *know* that the
> little classes JRuby generates for jitted Ruby methods are getting
> collected just fine, and I have seen them inline. So it seems the JVM
> handles these cases ok.

I see... well that is what I would suspect as well.. on the other hand, 
would that be *not* the case, I would feel much better for 
MethodHandles, since it would assure me that this makes no practical 
difference... but then of course I will still have to think hard to find 
a replacement for the current memory aware implementation.

>> 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.
>
> Understood. Yes, I'd like a clarification here too. I'm not concerned
> about making call site weakly reference the target handle, but it's an
> interesting case; you want to be able to inline just as well, but not
> necessarily hold hard references in some cases.

yes

bye Jochen

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