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 <[EMAIL PROTECTED]> 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
signature.asc
Description: This is a digitally signed message part
