In my experience GC tuning often makes a larger difference than fully
optimized code generation. Thus anything that doubles our footprint
will probably tend to be perceptively slower in larger systems under
load (these things don't seem to be so perceptable with microbenchmarking).
-andy
Santiago Gala wrote:
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
--
Andrew C. Oliver
SuperLink Software, Inc.
Java to Excel using POI
http://www.superlinksoftware.com/services/poi
Commercial support including features added/implemented, bugs fixed.
