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, 31 Oct 2005 23:56:08 GMT
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
View raw message