Good email thread! Lots of different opinions have been expressed. It seems
there are valid reasons to support both JIT and interpreter in Harmony VM.
Looking into the future, it seems the Harmony modular framework needs to
allow both JIT and interpreter modules to be plugged in.
Designing a VM modular framework to accommodate JIT as well as interpreter
brings up entirely new design topics. Perhaps a new thread on these issues
will emerge.
Steve Liao, Intel Managed Runtime Division
On 9/23/05, Graeme Johnson <[EMAIL PROTECTED]> wrote:
>
> "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote on 09/22/2005 06:34:44 AM:
>
> > [SNIP]
> > > Geir> Basic thought is yes, I always figured we'd have this
> > > pluggable, with
> > > Geir> an interpreter for ease of porting, and then platform-
> > > specific JIT.
> > >
> > > It seems to me that there's a design question here. For instance, if
> > > you want to eventually take interpreted code and compile it (when it
> > > is "hot"), for full pluggability your JIT(s) and your interpreter need
> > > to agree on some set of bookkeeping details in order to make this
> > > possible. OTOH, you could make other decisions that make this problem
> > > go away, for instance having a single choice of execution engine up
> > > front; so the "fast JIT" and the "optimizing JIT" are just part of the
> > > same code base and only need to talk to each other, and can be built
> > > in an ad hoc way.
> > >
> > >
> > > Personally I'd be just as happy if we only had a JIT. There are
> > > already plenty of interpreters out there.
> >
> > But I would think that we'd want both, right? An interpreter that
> > builds on anything to ensure wide platform portability, with the the
> > ability to augment with a JIT for those platforms for which people
> > are interested in creating a JIT...
>
> Our experience with the J9 virtual machine has shown that supporting both
> interpreter and JIT solutions provides a valuable degree of flexibility.
>
> Bytecode interpreters have several advantages:
>
> - Portability: Support for rapid bootstrapping of new platforms by virtue
> of being easier to port.
>
> - Size: Very compact interpreters (<100K) can be constructed for memory
> constrained environments.
>
> - Flexibility: A well-written interpreter is easy to modify for research
> or experimental purposes and can trivially support runtime-pluggable
> features like debug and instrumentation.
>
> Admittedly, supporting combined interpreter/JIT modes does require careful
>
> attention to stack frame design and associated stack walking code. And
> yes, the transition between interpreted and native code (either JIT'ed or
> JNI) requires some special handling. However, good stack frame design is
> critical to efficiently supporting several other critical areas of the JVM
>
> including exception throw, GC, and debug support.
>
> IMO the relatively small amount of extra code to maintain the interpreter
> and extra stack walk support is well worth the effort.
>
> Graeme Johnson
> J9 VM Team, IBM Canada.
>
