harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Edworthy" <pe...@edworthy.org>
Subject Re: [arch] Interpreter vs. JIT for Harmony VM
Date Wed, 21 Sep 2005 10:52:00 GMT

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

I'd vote with a zero optimizing JIT. My reasons are not so much based on
speed, but on code reuse. The structures required to support this would
also be used by optimizing JITs. In an interpreter and JIT system the two
tend not to overlap as nicely. Less code & concepts to understand =
better, IMHO.

> 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.

(This is at the edge of my knowledge, I've read about it but never tried it)
If the JIT is a bottom up pattern matching compiler, which seems to fit
well with the Java Byte Code format, then populating the 'pattern tables'
especially if not aiming for much if any optimization would be just as
easy as setting up EEs.

> 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. 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.

For Magnus an example to explain the above.

a = sin (b) compiles to something like

load b
call sin
mov a

If the sin function is native then for an interpreter the process would be

read load b; push
carry out equivalent operation
read call sin
Find sin method is native
call native call routine
  call sin
  return sin return
read pop; mov a
carry out equivalent operation

so the call to the sin function is actually two jumps, which is bad as
jumps take time and often invalidate the data cache in the processor.

If compiled then it would be

load b; push; call sin; pop; move to a

There is only one call to get to the sin method

> 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?
Again less is more ;-}>

Peter Edworthy

View raw message