What don't you emerge it? :)
geir
On Oct 2, 2005, at 7:17 PM, Steve Shih-wei Liao wrote:
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.
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
