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 Tue, 08 Nov 2005 15:28:28 GMT
 Here I'm resending my earlier posting in order to have a typo fixed
("excusively" should have been "exclusively"). Thanks for your time:
--------------------------------------------------------------------

Good question! I'll reply according to the 4 areas in the previous email:
abstracting over the mode of execution, asynchronous compilation,
reentrancy, and supporting the mixing of JIT and interpreter.

The Execution Manager (EM) could be designed to host both JIT as well as
interpreter. The EM could also contain the execution policy. For example,
interpret exclusively or interpret until certain thresholds are crossed then
JIT. One way of doing this is to have the EM build an internal configuration
data structure to would hold the execution policy. The policy would be
loaded via a *.properties file or even developer time makefile parameters.

There are a number of ways to support asynchronous
compilation/re-compilation. For example, a timer based approach would sample
method hotness for a time interval of "X", then recompile the hotest methods
first in a separate thread. The java app threads continue without
disruption.

Harmony JVM needs to be designed to support non-reentrant JITs as a default.
It also needs to be designed to take advantage of reentrant JITs. This is
particularly important as the industry moves to multicore.

To have clean, easy to maintain Execution Manager interfaces, there needs to
be well thought out JIT ABI to C/C++ ABIs. This will allow activation
records from JIT code to interoperate with activation records from an
interpreter written in C/C++. Although this is messy and tedious work,
getting the ABI issues sorted out early will make development of pluggable
JITs and interpreters much easier. This in turn will allow Harmony to
support a larger number of active developers/committers than would otherwise
be possible.

Steve Liao, Intel Managed Runtime Division

On 11/8/05, Steve Shih-wei Liao <liao24@gmail.com> wrote:
>
>  Good question! I'll reply according to the 4 areas in the previous email:
> abstracting over the mode of execution, asynchronous compilation,
> reentrancy, and supporting the mixing of JIT and interpreter.
> The Execution Manager (EM) could be designed to host both JIT as well as
> interpreter. The EM could also contain the execution policy. For example,
> interpret excusively or interpret until certain thresholds are crossed then
> JIT. One way of doing this is to have the EM build an internal configuration
> data structure to would hold the execution policy. The policy would be
> loaded via a *.properties file or even developer time makefile parameters.
>
> There are a number of ways to support asynchronous
> compilation/re-compilation. For example, a timer based approach would sample
> method hotness for a time interval of "X", then recompile the hotest methods
> first in a separate thread. The java app threads continue without
> disruption.
>
> H
> armony JVM needs to be designed to support non-reentrant JITs as a
> default. It also needs to be designed to take advantage of reentrant JITs. This
> is particularly important as the industry moves to multicore. To have
> clean, easy to maintain Execution Manager interfaces, there needs to be well
> thought out JIT ABI to C/C++ ABIs. This will allow activation records from
> JIT code to interoperate with activation records from an interpreter written
> in C/C++. Although this is messy
> and tedious work, getting the ABI issues sorted out early will make
> development of pluggable JITs and interpreters much easier. This in turn
> will allow Harmony to support a larger number of active
> developers/committers than would otherwise be possible.  Steve Liao, Intel
> Managed Runtime Division
>
>
>  On 10/31/05, Geir Magnusson Jr. <geirm@apache.org> wrote:
> >
> > So what does that interface look like? Have any suggestions?
> >
> > geir
> >
> > On Oct 30, 2005, at 8:51 PM, Steve Shih-wei Liao wrote:
> >
> > > 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
> > >>
> > >>
> > >>
> > >
> >
> > --
> > Geir Magnusson Jr +1-203-665-6437
> > geirm@apache.org
> >
> >
> >
>

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