[Caml-list] Tail calls in the JVM and the OCamlJava project
Jon Harrop
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.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
_______________________________________________
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
fo...@x9c.fr
>
> 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
Jon Harrop
> - more aggressive unboxing of values, like in ocamlopt (**).
Can you elaborate on this? Surely boxing is no longer an issue thanks to JIT
compilation?
On a related note, the new code generator in Mono 2.2 has made F# Mono as fast
as OCaml on SciMark2. So a Mono backend might be a viable option.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
_______________________________________________
fo...@x9c.fr
> On Tuesday 27 January 2009 08:36:23 fo...@x9c.fr wrote:
> > - more aggressive unboxing of values, like in ocamlopt (**).
>
> Can you elaborate on this? Surely boxing is no longer an issue thanks to JIT
> compilation?
I was refering to the fact that some OCaml values (such as int32, int64, int,
float) could be mapped to Java primitive types, at least for intermediary
results. As of today, the ocamljava compiler will use boxed representation
for all but int values. Further, I think that the unboxing done for int
values could be made more aggressive.
As a result, numerous intermediate values are created and just dropped,
which results not only in slower code but also in additional pressure
on the garbage collector.
Given that this boxing is not done via Java "wrapper" classes (but custom
classes encoding OCaml values), it seems almost impossible that the JVM
JIT optimizes this boxing.
> On a related note, the new code generator in Mono 2.2 has made F# Mono as
> fast
> as OCaml on SciMark2. So a Mono backend might be a viable option.
Sure. To me, any major virtual machine is a good candidate as a target.
Moreover, Sun and Microsoft virtual machines are quite similar so
there is no obvious reason why the work done for the JVM could not
be done for dot net.
Xavier Clerc
Jon Harrop
> On a related note, the new code generator in Mono 2.2 has made F# Mono as
> fast as OCaml on SciMark2. So a Mono backend might be a viable option.
Turns that tail calls are not yet implemented in Mono so forget that...