From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA05137 for caml-red; Wed, 3 Jan 2001 14:36:43 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA10028 for ; Wed, 3 Jan 2001 13:15:11 +0100 (MET) Received: from nef.ens.fr (nef.ens.fr [129.199.96.32]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f03CFAb11356 for ; Wed, 3 Jan 2001 13:15:10 +0100 (MET) Received: from clipper.ens.fr (clipper-gw.ens.fr [129.199.1.22]) by nef.ens.fr (8.10.1/1.01.28121999) with ESMTP id f03CF8M20621 ; Wed, 3 Jan 2001 13:15:08 +0100 (CET) Received: from localhost (frisch@localhost) by clipper.ens.fr (8.9.2/jb-1.1) id NAA17858 ; Wed, 3 Jan 2001 13:15:08 +0100 (MET) Date: Wed, 3 Jan 2001 13:15:08 +0100 (MET) From: Alain Frisch To: Markus Mottl cc: Mattias Waldau , OCAML Subject: Re: JIT-compilation for OCaml? In-Reply-To: <20010102203051.A18481@miss.wu-wien.ac.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: weis@pauillac.inria.fr Hello, my 0.02 euros ideas about a JIT for OCaml: There are basically two ways to JIT-compile a bytecode program: at startup or during runtime. Compiling the bytecode at startup makes sense for instance for web distributed code (applets). Otherwise, if the code is to be used more than once by a given user, it's better to convert statically the bytecode to native code. Hacking ocamlrun to produce native code simply by expanding each opcode from the abstract machine seems fairly easy. Some optimizations are lost. Another idea would be to make the compiler outputs the "lambda" intermediate code (shared between ocamlc and ocamlopt) and distribute it, maybe with some modification to prevent reverse engineering. The backend of ocamlopt (code generation) is run by the user to produce an executable program. 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). Happy new year to everybody ! -- Alain Frisch