On Wed, Jan 27, 2010 at 10:16 AM, John Rose <john.r...@sun.com> wrote: > They also provide a way to do something like bytecode-level templating, since > CP elements can be varied while the rest of the code is held fixed. I hope > somebody experiments with loop customization at some point, using anonymous > classes or a higher-level bytecode weaver. But that's in the future.
I've done minor experimentation with AnonymousClassloader, as you know, and it's certainly fun...but the use cases for templating in general-purpose applications seemed to be a bit limited. In JRuby's case, the primary interesting case was for generating our little invoker classes...basically our equivalent of method handles, which obviously isn't necessary if we can just use method handles :) The other use case, which I did not attempt, was in regenerating call sites a la the DLR's DynamicSite logic (which repeatedly regenerates a call site with a series of instanceof checks, to specialize the call paths iteratively). Again, InvokeDynamic potentially handles this better? > The uses you and Charlie point out are less important that they seemed at > first for two reasons: > > 1. Method handles provide a better replacement for the swarm of tiny classes. > > 2. Hotspot is in the process of weaning itself off of perm gen. One of the > main features of perm-gen is that its objects never move except during full > GC, and the code cache relied on this invariant until just last year, with > the 'ScavengeRootsInCode' changes. If permgen goes away, there's still the classloader-rooting problem that requires constructing a new classloader for every tiny class you want to be GCable. If JRuby, for example, wanted to start "tiering" our optimization phases, we'd have to use scads and scads of classloaders to ensure the old method bodies could go away. So that use case is still alive and well. - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
