question regarding call sites and garbage collection
Charles Oliver Nutter
headius at headius.com
Thu Mar 17 11:39:23 PDT 2011
On Thu, Mar 17, 2011 at 10:39 AM, Jochen Theodorou <blackdrag at gmx.org> wrote:
>
> 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.
Grr. I hate mailing lists that don't reply to list. I don't care about
some perceived fear of auto-replies flooding the list. I always want
to reply to list :(
Thanks for catching my mistake.
> 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 ;)
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.
> 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.
> For that too 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.
> 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.
- Charlie
More information about the mlvm-dev
mailing list