English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Tail calls in the JVM and the OCamlJava project
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-01-27 (14:42)
From: forum@x...
Subject: Re: [Caml-list] Tail calls in the JVM and the OCamlJava project
Selon Jon Harrop <jon@ffconsultancy.com>:

> On Tuesday 27 January 2009 08:36:23 forum@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