[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jerry Jackson <jrj@c...> |
| Subject: | RE: JIT-compilation for OCaml? |
-----Original Message----- From: Alain Frisch [mailto:frisch@clipper.ens.fr] Sent: Wednesday, January 03, 2001 5:15 AM To: Markus Mottl Cc: Mattias Waldau; OCAML Subject: Re: JIT-compilation for OCaml? Hello, Compiling the code really during runtime opens the door to further optimizations (I guess this is how Java JIT compilers work, but I have no idea). For instance, it is possible to watch conditionnal jumps and reorganize the code so that the most taken branches don't need any jump. The GC and the memory allocator have the opportunity to adapt themselves to the application. Of course, this only makes sense for long running applications. The user should be able to record the optimization information collected. Actually, there are two operations involved: a profiler (a bytecode interpreter that also collects optimization information) and a bytecode-to-nativecode converter as in the previous paragraph. I don't see the advantage of mixing them in a complex JIT compiler (which will be slow for a long time after startup if the optimizations are non trivial). [JRJ] There are many other sorts of optimizations that can be done by compiling at runtime. A simple case is that processor-specific instructions can be generated instead of generic ones (e.g. Pentium III instructions rather than generic 486). A more interesting example is used by Sun's current JIT compiler... Aggressive inlining and direct dispatch are done for all sorts of method calls (that could potentially be overloaded). If a class is later loaded that extends one of the inlined or directly called methods, the JIT compiler goes back and "unoptimizes" the code it had previously optimized!