Am 16.03.2011 20:06, schrieb Charles Oliver Nutter: > On Wed, Mar 16, 2011 at 3:36 AM, Jochen Theodorou<[email protected]> 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 _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
