harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Shih-wei Liao <lia...@gmail.com>
Subject Re: [arch] Interpreter vs. JIT for Harmony VM
Date Mon, 31 Oct 2005 01:51:33 GMT
Sure. (I had been out of country until last weekend.)
 Since there is a reason to support both JITs and interpreters, we should
keep the option open to have interpreters and JITs.

I think the modular interface from the VM core to Execution Engines should
support both JITs and interpreters. Execution Engine interface should
abstract over the mode of execution. This will cover a wide spectrum of the
market segments. Cell phone environment may demand an interpreter or a
light-weight JIT with small memory footprint. Server market segment probably
prefers a powerful JIT.

The issues of supporting both JITs and interpreters include:

- Asynchronous compilation: Execution Manager can have a time-based
interrupt to invoke Execution Engines to recompile.

- Re-entrant JIT: Many JITs are not re-entrant. When running, for instance,
MTRT in SPECJVM, because multiple threads are running, multiple JITTing may
happen concurrently if there is no locking. The Execution Manager can put
locks before each JITTing in order to ensure that no multiple JITTing is
going on concurrently.

But if we want to allow concurrent JITTing, I think the JIT needs to be
changed to stateless and some VM data structures that a JIT accesses needs
to be changed to allow concurrency.

- For the mixing of native frames and Java frames, who should own the stack
layout (format of JIT and interpreter stack layout)? Probably VM? For
example, GC should talk to that owner for the root set.
Any thoughts?
 Steve Liao, Intel Managed Runtime Division
 On 10/2/05, Geir Magnusson Jr. <geirm@apache.org> wrote:
>
> 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 <Graeme_Johnson@ca.ibm.com> wrote:
> >
> >>
> >> "Geir Magnusson Jr." <geirm@apache.org> 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
> geirm@apache.org
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message