Re: Why interpret dynamically loaded classes?

[Bryce McKinlay <bryce at albatross dot co dot nz>]

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 is certainly possible, but for most applications it wouldn't make much
sense. Aside from the obvious problems of needing to ensure a consistent
environment (libgcj can't assume gcj is available, and wouldn't know where to
find it if it was), what you're getting is essentially an extremely slow JIT,
without any of the dynamic optimization benefits of a real JIT. jc1 must be
invoked separately for each class file that requires compilation, and if
several hundred classes needed to be loaded then we're easily talking minutes,
rather than milliseconds, of compilation overhead.

gcj's interpreter makes a lot of sense in situations where you want to
dynamically modify a program's behaviour without having to restart or recompile
it. Its easy to imagine native java applications that, for convenience, can
accept plug-ins or scripts in the form of .class files. The current interpreter
is not fast, but it is trivial to use and doesn't have any significant startup
overhead.

Ideally, libgcj will get a real JIT...

regards

  [ bryce ]