harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: [arch] Interpreter vs. JIT for Harmony VM
Date Mon, 03 Oct 2005 04:31:41 GMT
What don't you emerge it?  :)


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

View raw message