Why interpret dynamically loaded classes?

[Jack Andrews]

From: Andrew Haley [ mailto:aph@cygnus.co.uk ]
> Elmar Haneke writes:
>  > Jack Andrews wrote:
>  > 
>  > > I note that both GCJ and TowerJ use a bytecode 
> interpreter to handle dynamic
>  > > class loading. But why not just compile the dynamically 
> loaded class to a
>  > > native shared object at *runtime*, then link at runtime, too?
>  > 
>  > This might be done!
>  > 
>  > But, I would expect it to be rather slow
> 
> Perhaps, but I really like this idea.  I've been thinking of doing
> this for a while but I've never found the spare time to try it.  I
> don't think it would be very difficult.

I'd be interested in helping the effort.  I'm not familiar with gcj, but I'd
really like to see this happen.  It kind of unifies things -- *all* code is
compiled before use.  

I see this as useful for server processes where first-time start-up is not
significant.

Note that there would only be first-time start-up penalty.  Every subsequent
start-up would have a native shared object sitting in the 'repository'.  Of
course, if the class bytecode changes, a re-compile is necessary. 

I guess, at every subsequent start-up, the shared object could be statically
linked into the main executable for efficiency.  That's *another* research
project, though :)