caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: David Gurr <gurr@mrs.med.ge.com>
To: Basile.Starynkevitch@cea.fr
Cc: caml-list@inria.fr
Subject: IBMs UVM?  RE: JIT-compilation for OCaml?
Date: Thu, 4 Jan 2001 12:48:09 -0800 (PST)	[thread overview]
Message-ID: <200101042048.MAA05288@mrs.mrs.med.ge.com> (raw)

OK, JVM is not an ideal target for compiling ML.  But what about
IBM's UVM.  Does anyone here know about IBM's VMs?  I have seen
hints that UVM started life as a VM for Smalltalk.  If so, it
is probabaly ML friendly.  Does anyone know more about this?

STARYNKEVITCH Basile:
> It is well known (e.g. see the Kawa implementation of Scheme on the
> JVM) that the Java Virtual Machine is not well suited for functional
> programming: function closures and tail-recursion calls (which are
> actually jump with arguments) do not exist in the JVM, and emulating
> them (e.g. closures as instances of specially generated classes) is
> quite inefficient. The JVM is not as universal as Sun's marketing hype
> claim it is...
> 
> On the contrary the Ocaml virtual machine was (of course) designed for
> functional programming, and efficiently implement tails calls and
> closure constructions.

There are a number of gotchas with compiling Ocaml to JVM but closures
are not really the problem.  Jumps do exist but they are only "within a
method"  Which means that you get lots of code duplication if you do a
naive compilation of a let rec.  But if you try the MLj (a SML to JVM
compiler written in SML) you will see that this really is not a
problem.  If I had to point to one single difference between the java
and ocaml runtimes that really simplifies compilation of Ocaml it would
be the universal data type (ie the union of 31 bit tagged ints and 32
bit pointers -- for 32 bit machines of course).  This makes it easy to
compile efficient polymorphic code.  With JVM you need to monomorphise
the code.  If you do so at compilation time you need the whole program
(al MLj and Milton) which works but ... .  But if the point of JVM is
to do JIT then it makes sense to do monomorphing at JIT time.  And
there are hooks to JVM so you can do this (and some people doing
generics for java have tried this).  My opinion after doing a fair bit
of this is that the Ocaml implementation is oh so much nicer to work
with so I've mostly lost interest in the subject.  A more promising
direction is to compile java to a 64bit ocaml runtime.  But I think
the Ocaml group does not like that idea.

- David Gurr

MLj : http://www.dcs.ed.ac.uk/home/mlj/



                 reply	other threads:[~2001-01-04 21:18 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200101042048.MAA05288@mrs.mrs.med.ge.com \
    --to=gurr@mrs.med.ge.com \
    --cc=Basile.Starynkevitch@cea.fr \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).