harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@apache.org>
Subject Re: [arch] Interpreter vs. JIT for Harmony VM
Date Wed, 21 Sep 2005 23:08:38 GMT
El mié, 21-09-2005 a las 08:29 -0700, will pugh escribió:
> 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.
> 

3) Memory. A typical fast, non opt JIT will generate 10-15 bytes of
machine code *per bytecode*. This means that, say, tomcat plus typical
web applications will generate more than 20Megs of jitted code that will
be executed just a few times. A fast interpreter+optimizing compiler
would achieve similar performance and save most of those 20Megs.

I've seen this going on in my efforts to get jetspeed running on top of
jikesRVM+classpath (which is leading to a series of bug reports to both
projects).

I have it running, in my linux-ppc TiBook, only one problem with
ClassLoader.getResource that is proving difficult to solve is remaining
for a full success. :)

Tomcat+Jetspeed runs (qualitatively) faster using an Optimized JikesRVM
+classpath version in my TiBook than using IBM-jdk-1.4.2, but it
requires 200 M heap, while IBM jdk runs it in 100 Megs. Also, startup
time is about the same or slightly higher, but this is mostly because I
don't opt-compile the optimizing compiler itself to save build time.

Example output from a typical run:

                Compilation Subsystem Report
Comp   #Meths         Time    bcb/ms  mcb/bcb      MCKB    BCKB
JNI        35         2.44        NA       NA      15.5      NA
Base    26074      8082.06    194.01    10.51   22977.7  2186.7
Opt       722     14685.43      2.46     6.76     226.7    33.5


Regards
Santiago

>     --Will
> 
> 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
> >>>environment.
> >>>      
> >>>
> >
> >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
> >compiler).
> >
> >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.
> >
> >Tom
> >  
> >
-- 
VP and Chair, Apache Portals (http://portals.apache.org)
Apache Software Foundation

Mime
View raw message