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<[email protected]> 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 _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
