Am 17.03.2011 19:39, schrieb Charles Oliver Nutter: > On Thu, Mar 17, 2011 at 10:39 AM, Jochen Theodorou<[email protected]> 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 _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
