harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From will pugh <willp...@sourcelabs.com>
Subject Re: [arch] Interpreter vs. JIT for Harmony VM
Date Wed, 21 Sep 2005 15:29:47 GMT
I think having a FastJIT and forgoing the interpreter is a pretty 
elegant solution, however, there are a few things that may come out of this:

  1)  Implementing JVMTI will probabaly be more difficult than doing a 
straight interpreter
  2)  The FastJIT needs to be Fast!  Otherwise, you run the risk of 
people not wanting to use it for IDEs and Apps because the startup time 
is too slow.


Tom Tromey wrote:

>>>>>>"Geir" == Geir Magnusson <geirm@apache.org> writes:
>>>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
>Geir> I believe you, but I don't understand this.  Can you explain in more
>Geir> detail?
>It is about handling calling conventions.
>There are conceptually (at least) 2 cases to consider when
>implementing the java 'invoke' family of opcodes in an interpreter.
>In the first case, suppose you're invoking another method that you
>know is interpreted.  In this case you might simply make a recursive
>call to the interpreter function itself, passing in new locals as an
>array or something.  The interpreter itself might look something like
>(I'm just making this up, but it is reasonably close to, e.g., what
>libgcj does):
>  void interpret (jclass declaringClass, jmethodID method,
>                  union jslot *locals)
>... where jslot corresponds to a single stack or local variable slot
>as discussed in the JVM spec.
>So to make your call you would look up the method and pass slots from
>your current stack as the 'locals' argument.
>(Note that you aren't required to do things this way; in libgcj we
>only use the native ABI and we don't special case calls to interpreted
>methods at all.  We probably pay some performance penalty for
>this... though the interpreter is plenty slow on its own :-)
>In the second case, you're calling some function that is not an
>interpreted function, e.g. a native method.  In this case the
>underlying function will be using whatever low-level function calling
>ABI is defined by the current platform (and implemented in the C
>There is no standard way in C to make such calls.  Instead you end up
>having to use something like libffi -- a piece of code that translates
>from some array-of-arguments view to the low-level register twiddling
>required to make an arbitrary C call.
>For a JIT the situation is different.  A JIT already understands a lot
>about register twiddling.  I don't know whether it is common to use
>the C ABI when writing a JIT, but in any case it would seem that
>putting this in there as well is no big deal.  Then instead of
>figuring out at call time how to make a given call, you simply
>determine it at compile time and generate the appropriate code.
>>>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?
>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.

View raw message