indy and tailc

[Charles Oliver Nutter]

On Wed, Jan 27, 2010 at 10:16 AM, John Rose <John.Rose at 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