Re: [Caml-list] Tail calls in the JVM and the OCamlJava project

[forum@x9c.fr]

Selon Jon Harrop <jon@ffconsultancy.com>:

>
> For anyone who missed it, there has been a very interesting development in
> JVM
> land. Arnold Schwaighofer claims to have the first working implementation of
> tail calls on the recently open sourced Hotspot Java compiler:
>
>   http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000331.html
>
> Given the existence of the OCamlJava project, this should be of great
> interest
> to the OCaml community because it might pave the way to even better numerical
> performance and easier parallelism with simple interop to rich libraries and
> so forth.

The work done around the Da Vinci machine
(http://openjdk.java.net/projects/mlvm/)
is clearly interesting for the future of the OCaml-Java project (and for almost
any compiler targeting the JVM). However, we have no evidence regarding the
'transfert rate' from the Da Vinci machine to the 'plain' JVM.

That being said, some other developments are needed before we get decent
performances from ocamljava-compiled code. Not trying to be exhaustive, I
would list:
  - tail calls (*);
  - garbage collector strategies better suited to functional languages (*);
  - some kind of 'method pointers' for efficient closure handling (*)
    cf. http://jcp.org/en/jsr/detail?id=292
  - a better memory model (**);
  - a better code generator (**);
  - more aggressive unboxing of values, like in ocamlopt (**).

Items marked by (*) are related to the JVM while those marked by (**) are
developments to be done on the OCaml-Java codebase. One chance for the
OCaml-Java project is that the hype around so-called scripting languages
seems to push Sun to design and integrate things that are useful to
OCaml-Java. Indeed, scripting languages and OCaml express some common
needs such as garbage collectors oriented towards short-lived objects,
or function/method pointers. Almost all that benefits to scripting
languages will also benefit to OCaml-Java.

Anyway, we will have to wait until JDK 7 (planned / hoped for late 2009)
to see some of these changes available for production. In the meantime,
I will have to find some time to work on OCaml-Java to correct its
deficiencies.


Xavier Clerc