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