Re: [Caml-list] Alternative Bytecodes for OCaml

["Basile Starynkevitch [local]" <basile.starynkevitch@inria.fr>]

On Wed, Aug 25, 2004 at 09:26:28AM -0500, John Goerzen wrote:

John> I come to OCaml from a Python background, and one of the most 
John> interesting bits of technology for Python is Jython[1].  Jython is a 
John> pure Java implementation of the Python interpreter and native-code 
John> libraries.  It allows Python programs to run unmodified in a Java 
John> environment.  More powerfully, though, Python programs can use Java 
John> classes as if they were native classes. [....]

I see several reasons against using the JVM in eager functional
languages like Ocaml (I'm recalling some papers, but I forgot the
references)

   The garbage collector has different requirements in Java (JVM) and
   in Ocaml. Java is multi-threaded (in the sense that several threads
   are executing Java bytecode simultanously), but Ocaml is not really
   multi-threaded (in the sense of simultanous bytecode
   execution). Also, Java style favors big mutable objects, while
   functional style suggests many small immutable tuple blocks (i.e. tuples or
   records in Ocaml source language) with quick allocation.

   IIRC, the minimal Java overhead for any Java objects is 2 words
   (one for the class pointer, one for a serial number), while the Ocaml
   memory overhead is usually one word (for the block header, containing
   the tag & the block size).

   Ocaml runtime (and GC) is optimized for fast allocation of tuple
   (in the runtime sense) block values, and for quick tag inspection
   (useful for pattern matching) - allocating such a tuple is much
   faster than allocating a Java object (because there is no
   synchronisation issues)

   The JVM bytecode specification does not support tail-calls (which
   is really needed in functional languages) and do not provide quick
   closures (closures could be emulated by inner classes instances in
   JVM, but they would be much slower)

The substantial differences in the GC, and the lack of closure &
tailcall support in JVM is a well known barrier against using the JVM
for functional language implementations. In other words, even if some
Java enthusiasts tell otherwise, the JVM is not the universal UNCOL of
our time!

Even if the JVM specification was extended (for tail calls &
closures), the resulting implementation[s] would very probably be
slower than Ocaml (because Java requires different trade-off than
Ocaml).

Regards.
-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
other email : basile at starynkevitch dot net
Project cristal.inria.fr - temporarily 
http://cristal.inria.fr/~starynke --- all opinions are only mine 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners