English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
RE: JIT-compilation for OCaml?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-01-04 (13:06)
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?


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!