You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Steve Shih-wei Liao <li...@gmail.com> on 2005/10/03 01:17:09 UTC
Re: [arch] Interpreter vs. JIT for Harmony VM
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 <Gr...@ca.ibm.com> wrote:
>
> "Geir Magnusson Jr." <ge...@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.
>
Re: [arch] Interpreter vs. JIT for Harmony VM
Posted by Steve Shih-wei Liao <li...@gmail.com>.
Mr. Shudo,
I'm not aware of any commercial JIT today that compiles the same method
simultaneously. This is probably because today even if a JIT is re-entrant
and the locking/contention is minimal, there is no clear benefit from
running multiple "jit_me()" simultaneously. (I use "jit_me" to refer to the
stub function that invokes the compiler. Vtable's method entries are
initialized with the pointers to "jit_me"). If each of the multiple jittings
has incomplete profile information, it is probably better if the Execution
Manager consolidates the profile information and then let one jitting
proceed in order to generate the best code with more complete picture.
Multiple jittings are more likely as multicore becomes prevalent, but there
is no requirement that they be done on the same method.
Regarding using separate jit threads vs. using application threads to do the
jitting, I think Harmony should support both. Harmony should also support
a hybrid approach that is in use today. The hybrid apporach uses application
threads for jitting and uses a separate jit-thread for re-jitting. When a
method is encountered for the first time, the running application thread
performs jitting and replaces the "jit_me" stub with the jitted code. Today,
typically at most one application thread will do the "jit_me" for the same
method, because running many instances of jit_me() function on the same
method hasn't been shown to yield clear benefit yet. Furthermore, since
typically there is only re-jitting thread today, there won't be simultaneous
rejitting of the same method either. On multicores, re-jittings can take
advantage of the otherwise-idle cores to do expensive jitting to generate
higher-quality code, while the application thread performs fast jittings.
Thanks,
Steve Liao, Intel Managed Runtime Division
On 11/14/05, shudo@computer.org <sh...@computer.org> wrote:
>
> From: Steve Shih-wei Liao <li...@gmail.com>
>
> > - 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.
>
> Do you know an actual JIT compiling the same method simultaneously?
>
>
> HotSpot VM has a thread dedicated to JIT compilation and the compiling
> thread receive a compilation request from a queue.
>
> A JIT I have developed took another way in which a thread executing an
> application compiles the application. The JIT allows multiple threads
> to do JIT compilation simultaneously but a method is not compiled
> multiple times because of appropriate locks assined to each stage
> of JIT compilation.
>
> There are choices on the relationship between threads and JIT
> compilation:
>
> - Separated threads dedicated to JIT compilation.
> - Number of locks by JIT gets fewer?
> - Compilation takes much time in case that there are many active
> application threads. It leads to further starvation.
> Note that HotSpot VM has -Xbatch option to lighten this problem.
> - Exploits more processors remaining?
>
> - Application threads which also perform JIT compilation.
> - Exploits multiple processors for JIT compilation naturally.
>
>
> Kazuyuki Shudo shudo@computer.org http://www.shudo.net/
>
>
Re: [arch] Interpreter vs. JIT for Harmony VM
Posted by sh...@computer.org.
From: Steve Shih-wei Liao <li...@gmail.com>
> - 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.
Do you know an actual JIT compiling the same method simultaneously?
HotSpot VM has a thread dedicated to JIT compilation and the compiling
thread receive a compilation request from a queue.
A JIT I have developed took another way in which a thread executing an
application compiles the application. The JIT allows multiple threads
to do JIT compilation simultaneously but a method is not compiled
multiple times because of appropriate locks assined to each stage
of JIT compilation.
There are choices on the relationship between threads and JIT
compilation:
- Separated threads dedicated to JIT compilation.
- Number of locks by JIT gets fewer?
- Compilation takes much time in case that there are many active
application threads. It leads to further starvation.
Note that HotSpot VM has -Xbatch option to lighten this problem.
- Exploits more processors remaining?
- Application threads which also perform JIT compilation.
- Exploits multiple processors for JIT compilation naturally.
Kazuyuki Shudo shudo@computer.org http://www.shudo.net/
Re: [arch] Interpreter vs. JIT for Harmony VM
Posted by Tom Tromey <tr...@redhat.com>.
Geir> What's an activation record?
Compiler speak for a stack frame.
http://en.wikipedia.org/wiki/Activation_record
Tom
Re: [arch] Interpreter vs. JIT for Harmony VM
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Nov 8, 2005, at 10:20 AM, Steve Shih-wei Liao wrote:
>
> 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.
Is it possible to have some kind of core-affinity for the JIT? So
non-reentrant JITs could be used in multicore systems w/o a rewrite?
> 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++.
What's an activation record? (I'd ask "why do they need to
interoperate", but I'll save that if your answer doesn't give me a
hint...)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [arch] Interpreter vs. JIT for Harmony VM
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Steve" == Steve Shih-wei Liao <li...@gmail.com> writes:
Steve> Harmony JVM needs to be designed to support non-reentrant JITs
Steve> as a default. It also needs to be designed to take advantage
Steve> of reentrant JITs. This is particularly important as the
Steve> industry moves to multicore.
What do you mean when you say "non-reentrant JIT"? A JIT that has
global variables and assumes it is only running in one thread at a
time? Or a JIT that assumes that it won't be interrupted (in a given
thread) to do some other piece of work? Or maybe something else?
Tom
Re: [arch] Interpreter vs. JIT for Harmony VM
Posted by Steve Shih-wei Liao <li...@gmail.com>.
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 <li...@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. <ge...@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. <ge...@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 <Gr...@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
> >
> >
> >
>
Re: [arch] Interpreter vs. JIT for Harmony VM
Posted by Steve Shih-wei Liao <li...@gmail.com>.
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.
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 10/31/05, Geir Magnusson Jr. <ge...@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. <ge...@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 <Gr...@ca.ibm.com> wrote:
> >>>
> >>>
> >>>>
> >>>> "Geir Magnusson Jr." <ge...@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
>
>
>
Re: [arch] Interpreter vs. JIT for Harmony VM
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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. <ge...@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 <Gr...@ca.ibm.com> wrote:
>>>
>>>
>>>>
>>>> "Geir Magnusson Jr." <ge...@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
Re: [arch] Interpreter vs. JIT for Harmony VM
Posted by Steve Shih-wei Liao <li...@gmail.com>.
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. <ge...@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 <Gr...@ca.ibm.com> wrote:
> >
> >>
> >> "Geir Magnusson Jr." <ge...@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
>
>
>
Re: [arch] Interpreter vs. JIT for Harmony VM
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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 <Gr...@ca.ibm.com> wrote:
>
>>
>> "Geir Magnusson Jr." <ge...@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