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