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
detail?
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
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
