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 Wed, 21 Sep 2005 10:00:35 GMT

On Sep 21, 2005, at 5:12 AM, Steve Shih-wei Liao wrote:

> Do we need an interpreter or a fast code generating, zero  
> optimizing JIT?

I'm learning the lingo - I assume you mean that the JIT does no  
optimization, just generates native code quickly?

I assume that yes, that would be nice.

> I
> can think of advantages to each approach. Assuming a C/C++  
> implementation, a
> traditional interpreter is easy to port to a new architecture and  
> we can
> populate Execution Engines (EE) for different platforms rather  
> easily.On
> the other hand, a fast code-generating JIT can call runtime helpers  
> and
> native methods without additional glue code whereas an interpreter  
> has to
> have special glue code to make it work in a JIT environment.

I believe you, but I don't understand this.  Can you explain in more  

> Needless to
> say, if a method is called more than once, the one time cost of JITing
> without optimization may be lower than the cost of running the  
> interpreter
> loop.
> Our experience is that a fast, zero optimizing JIT can yield low- 
> enough
> response time. So, I think at least Harmony has the option of having a
> decent system without an interpreter. Thoughts?
>  Steve Liao, Intel Managed Runtime Division

Basic thought is yes, I always figured we'd have this pluggable, with  
an interpreter for ease of porting, and then platform-specific JIT.   
Now, the "zero optimizing" JIT was something I imagined would be the  
simple, first-version JIT for a given architecture.  (capable of  
generating the native code, but no optimzation because that's harder :)

My mental model is what little I know about Intel's StarJIT :  I  
think about it via two phases of optimization.  First is a "global"  
optimization step in a platform-neutral IR, and the second is a  
platform-specific optimization step in the "platform module" that's  
responsible at the end for generating the native code.

java ->  IR -> [ global optimizer ] -> [platform JIT w/ optimizer] ->  
native code


Geir Magnusson Jr                                  +1-203-665-6437

View raw message