jikesRVM have 3 compilers, baseline, quick and opt. baseline is meant to have jit times comparable to an interpreter preparation time[1]. quick is a replacement for baseline on PPC, as the generated code is too slow, and aim to only get low hanging fruits. It's a linear, one pass compiles, so it doesn't perform any of the fancy (and time demanding) optimizations you suggest. opt is the optimizing compiler that goes as further as possible on performance.
HotSpot have interpreter, client and server compiler. The big diference is that in server mode code is recompiled once one of it's dependencies is resolved (think of incremental whole program global optimization) and speculative optimizations are done (like inlining/devirtualizing should-be-virtual methods) [2]. A good JVM needs not only great JITers and GCs, but work in a adaptative way, doing only the most profitable things for the user. Eg, if compiling with opt will take more time the total method execution time in interpreted mode, then don't. Rodrigo [1] SableVM shows that with some preparation interpreting can be a lot faster, see Etiene phd thesis for a great explanation about this. [2]OVM, I think, does some of this by class hierachy analisis for example. On 5/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > The JCVM docs talks about possible support for generating ELF binaries > > usign just Java code, although this doesn't appear complete at this > > point. See > > http://jcvm.sourceforge.net/share/jc/doc/jc.html#Java%20to%20ELF > > > > > > GCC also has its own internal format (called RTL I think). I don't know > > much (anything) about that, but it is easy to speculate about producing > > RTL from bytecode and feeding it to the compiler. I'd speculate that GCJ > > works something like this. > > > > RTL is Register Transfer Language I believe. RTL is kinda like an > abstract assembler language, however its not exactly multiplatform. > Meaning the RTL generated for each platform may differ. > > Writing a GCC front end is actually rather non-trivial I'm afraid. > While it does do a traditional AST tree more or less, its implemented > with some rather complicated and undocumented macros (and from what I > remember a few layers of them). > > Its unlikely that GCC is going to change license or offer an exemption > so more or less taking code from GCC itself is not legally feasible for > an ASL project. On the other hand, I'm not convinced that GCC is an > acceptable compiler for a JIT anyhow. Allow me to demonstrate. Find a > large C project (say 1000 sources). Build the project on a fairly fast > machine. > > Okay, now boot up your favorite Java Application Server (whichever that > may be). Imagine if it took that long to start up. Sure it would be > fast once it did. However, due to how default Java classloading works > (by lazy loading when it is asked for) there would be a perceived > performance impact. We COULD mark some classes hot and the such, but it > would still be jerky and appear slow. Its possible that you could rip > pieces of GCC out and construct a more traditional JIT, but its really > not what we want. > > So there are probably people here who know more about it than me. I'm > just a simple southern boy who reads compiler books in the bathroom. As > I understand it though, a runtime compiler requires a slightly blacker > belt of compiler writing. You need to not only try and generate > efficient native code, but optimize compiler time so that no one notices > that you did it! One approach to this is to generate code that has been > through the first few levels of optimization and then do the native > optimizations on another pass. (Generally starting up in interpreted > mode) This is actually kinda smart, because many of the highest yield > optimizations are these early optimizations (variable elimination, local > and global common subexpression elimination, algebraic simplification, > copy propagation, constant propagation, loop-invariant optimization, > etc). While the native and headier stuff should be done, since the Java > compiler can optimize and performs some optimizations, its unlikely to > be the highest yield most of the time. This does mean that more work > will have to be done and redone to get to the most optimal code, but the > pause should be low. > > Some of the things we COULD do to get things up and running are very > cool for that purpose, but ultimately we'll probably have to do the > heavy lifting of writing a JIT that balances the force while trying to > slay the complexity dragon.... > > -Andy > > > > >>Keep in mind I know squad about GCC and friends. > > > > > > Me neither. > > > > Nick > > > > > > IMPORTANT: This e-mail, including any attachments, may contain private > or confidential information. If you think you may not be the intended > recipient, or if you have received this e-mail in error, please contact the > sender immediately and delete all copies of this e-mail. If you are not the > intended recipient, you must not reproduce any part of this e-mail or > disclose its contents to any other party. > > This email represents the views of the individual sender, which do not > necessarily reflect those of education.au limited except where the sender > expressly states otherwise. > > It is your responsibility to scan this email and any files transmitted > with it for viruses or any other defects. > > education.au limited will not be liable for any loss, damage or > consequence caused directly or indirectly by this email. > > . > > > > > -- > 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. >
