On Sun, Feb 26, 2012 at 7:10 PM, Mark Roos <[email protected]> wrote: > I was wondering about the need to make the classes GCable. My first > approach used annoClasses > from sun.misc.unsafe but that turned out to have limited support so I went > to a 'normal' class > generation ( again like you one class per method). In looking over my code > it looked like about 50K > of these classes for a typical app with about 10% roll over for its life. > So I decided not to worry about > GCing the replaced classes. Does Ruby generate/replace lots of methods or > am I making a mistake > by not having a classLoader per class?
For you, it's probably not a big deal. For Ruby, it could be catastrophic. Ruby code does a lot more "meta" stuff with runtime code generation, sometimes via evaluating new code that's not visible to an ahead-of-time compiled, It's not a *lot* of new methods being generated (or methods being replaced) but it only takes a few of them periodically to slowly eat up memory. The price of a classloader per class is not trivial, but it's better than having a slow leak over time. We also have always intended to add a reoptimizing pass that throws out unused or rarely-used compiled methods and allows them to get hot again. If we wanted to do that periodically, we'd need arbitrary methods to be GCable. - Charlie _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
