"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.
