From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA27913 for caml-redistribution; Wed, 27 May 1998 11:22:27 +0200 (MET DST) 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 WAA18403 for ; Mon, 25 May 1998 22:03:36 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id WAA01961; Mon, 25 May 1998 22:02:26 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA32591; Mon, 25 May 1998 22:02:27 +0200 (MET DST) Message-ID: <19980525220227.04903@pauillac.inria.fr> Date: Mon, 25 May 1998 22:02:27 +0200 From: Xavier Leroy To: Ohad Rodeh , caml-list@inria.fr Subject: Re: Ocaml to Java References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Ohad Rodeh on Mon, May 18, 1998 at 09:19:24PM +0300 Sender: weis > SML to java bytecode has been written, see: > http://research.persimmon.co.uk/ > We, at the Ensemble project could use such a compiler. Even better > would be a compiler from Ocaml to Java (not bytecode). Is anything > in the works? The short answer is no. But since this question comes once in a while, let me elaborate. I have reviewed a fair number of "X-to-JVM" papers recently, and except when X is sufficiently close to Java (i.e. Eiffel or Ada-95), the results are universally negative. The papers report that the JVM code obtained by translation runs incredibly slowly (e.g. 10 times slower than a direct implementation of X with similar technology -- a bytecoded X against Sun's JDK for instance), is fairly large (due to code bloat during translation), and loads slowly (again, due to code bloat and the large number of small classes that need to be generated). All this shows that there is a deep mismatch between the languages being compiled and the Java/JVM execution model. So, compiling to JVM is essentially a failure, and I don't expect things to improve significantly in the near future. Java's compiler technology is nowhere progressing as fast as the Sun's marketroids would like you to believe. Everyone is obsessed with "killer JITs", but obviously you can't produce good machine code and produce it as fast as required for JIT operation. More importantly, even Java compilers based on more conventional technology (TOG's TurboJ, Harissa) are strongly biased towards "typical" Java programs, and for instance come with slow memory allocators and garbage collectors that are no match for Caml and other functional languages. So, I'm pretty sure a Caml-to-JVM or Caml-to-Java compiler would be essentially unusable because of its terrible performances, and I have no intention of working on one. This said, you could look at Pizza, an extension of Java with first-class functions, ML-style datatypes and ML-style polymorphism developed by Martin Odersky. A core Caml-to-Pizza translator would be relatively easy to write, since the most delicate ML features are handled by the Pizza-to-JVM compiler. Both the module language and the OO features of Objective Caml would be significantly harder to translate. More generally, I think you need to determine why you really want to translate Caml into Java. I can see several motivations: - You want to run your code as Web applets. Then, the JVM is pretty much unavoidable (altough there is this cool Caml plugin for Netscape...). But I don't see Ensemble fitting in this picture. Ensemble is a serious piece of systems software, and applets are throwaway toys. - You want to pursue Ensemble development in Java. Then, your only choice is to rewrite everything by hand in Java. There is no way an automatic translator can generate readable, maintainable Java code. In addition, the performance issues would be a major problem. To maximize performance, you'd need not only to hand-optimize the Java code, but also to re-engineer significantly the current Ensemble implementation so that it fits better the Java execution model. Then, after several man-years of effort, you might find that Java compilers and runtime systems are simply not good enough for your needs. - You want to use the Ensemble library from Java programs. Then all you need is Caml-Java interoperability via C. E.g. use the Java JNI interface to talk to Ensemble as if it were a C library, and the Caml-C interface to package up the Caml Ensemble code as a C library. The second half is already done, if I remember correctly. And the first half (JNI) should be fairly easy. Now, if you have questions to ask or experiences to report on Caml-Java interoperability via C, we would be very happy to discuss that with you. Best regards, - Xavier Leroy