[Caml-list] [ANN] OCaml-Java project: 1.4 release
fo...@x9c.fr
The goal of the OCaml-Java project is to allow seamless integration of OCaml and Java.
Home page: http://ocamljava.x9c.fr
Download page: http://ocamljava.x9c.fr/downloads.html
Toplevel applet: http://ocamljava.x9c.fr/toplevel/toplevel.html
Main changes since 1.3:
- upgrade from OCaml version 3.11.1 to 3.11.2
- improved (and simplified) code generator, with correct stack maps
- various code and documentation fixes
- improved build scripts
- bug #28 (Barista): support for ocamlfind
- bug #46 (Barista): invalid padding size for switch instructions
- bug #47 (Barista): invalid handling of '@LineNumber'
- bug #48 (Cadmium): error in 'mod_float' primitive implementation
- bug #50 (Nickel): GUI version ignores parameters
Xavier Clerc
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Warren Harris
I'd appreciate whatever information on this any of you can provide,
Warren
fo...@x9c.fr
Le 11 mai 2010 � 21:23, Warren Harris a �crit :
> I'm curious whether there are any notes / pointers regarding the completeness of the ocaml-java implementation (couldn't find this on the web site). I'm wondering about the feasibility of using it for a moderately large ocaml project I've been working on which uses Lwt to perform async I/O. I assume that for this to work with ocaml-java, the lowest levels of Lwt would need to be adapted to use NIO or threads in order to run on a JVM. Also my application is written in a pure functional style, and relies heavily on closures, currying, recursion and the ability for the compiler to do tail call optimization. I'm concerned that this will not translate well to Java.
Here is some information about the OCaml-Java project
(both current 1.4 release and future 2.0 release).
Regarding compatibility with the original implementation of OCaml:
- ocamljava is able to compile working versions of ocamlc, ocamllex, menhir and itself,
giving some confidence in its language-compatibility level;
- all the libraries bundled with the original implementation have been translated and
tested through some unit testing (but thread libraries tests are only lightweight, labltk
support is based on the swank project [1], and unix is only partially supported);
- document [2] gives per-primitive compatibility information;
- the last page of [3] lists the differences between ocamlc/ocamlopt and ocamljava compilers;
- third-party libraries (such as Lwt) should be supported out-of-the-box as long as they do
neither rely on exotic features (remember: "Obj.magic is not part of the OCaml language"),
nor on C code (unless you can translate it to Java code).
Regarding performances in current version:
- closures are based upon Java reflection (will be based upon JDK 7's method handles,
avoiding access checks on each call);
- only "explicit self" tail calls are optimized ("self" meaning same function, and "explicit"
meaning "not through a closure");
- performances are terrible and memory consumption is excessive.
Bottom line: the current version should be regarded as a proof-of-concept.
However, I have spent recent vacation on the upcoming 2.0 version, with some positive
results. The runtime has been partially rewritten, reducing memory consumption and
increasing performances. The Java equivalent of "ocamlrun" is now within an order of
magnitude from the original tool on all tested programs, and only about 4 times slower on some
(e. g. "nbody" from the language shootout [4]). This seems to indicate that -when updated-
the ocamljava compiler should be able to at least match ocamlc performances.
Notice that is a conservative statement / objective if you consider that Scala is on par with
ocamlopt on some benchmarks (but the Scala language has been designed from the bottom
up to be run on the JVM).
A final word about tail call optimization. As previously said, only "explicit self" calls are
optimized (as far as I know, this is also true for mature compilers like Scala or Clojure).
This will not change in future versions, unless Sun / Oracle adds support for tail calls in the JVM [5] [6].
I know that some people will regard a compiler for a functional language with no general
tail call optimization as "broken", but it is clear that OCaml-Java will not perform program
transformations (such as trampolining) to enable tail call optimization in every cases.
My understanding may be incorrect, but it seems that such transformations result in obfuscated
code (hindering HotSpot JIT compilation) and unpredictable performances.
Some points above may need to be elaborated, but this very message is already quite long...
Anyway, feel free to ask for further information.
Regards,
Xavier Clerc
[1] http://www.onemoonscientific.com/swank/summary.html
[2] http://cadmium.x9c.fr/distrib/cadmium-compatibility.pdf
[3] http://cafesterol.x9c.fr/distrib/cafesterol.pdf
[4] http://shootout.alioth.debian.org/
[5] http://openjdk.java.net/projects/mlvm/subprojects.html#TailCalls
[6] http://wikis.sun.com/display/mlvm/TailCalls