Date: Mon, 25 May 1998 22:02:27 +0200
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Ohad Rodeh <orodeh@cs.huji.ac.il>, caml-list@inria.fr
Subject: Re: Ocaml to Java
In-Reply-To: <Pine.BSI.3.96.980518211726.12946K-100000@hawk2.cs.huji.ac.il>; from Ohad Rodeh on Mon, May 18, 1998 at 09:19:24PM +0300
> 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
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:14 MET