graydon: The runtime cost of a particular VM doesn't end with the bag of goodies that it may or may not provide; VMs also impose assumptions about what the target architecture looks like, and provide constraints on the freedom of compiler writers on how they realise their language. I've generally looked at these infrastructure costs as being the more important question to ask about a VM. They seem to be the reason why FP implementers have mostly been lukewarm about the LLVM.
It's a fair point that there's a lot of hard work involved in providing tasty bags of goodies in the runtime; the effort that has been put into duplicating the JVM's runtime outside the JVM (i.e. Gnu Classpath, though I guess the free JVM's can be mined for suitable code) lags behind what Hotspot provides. I tend to think that, while this matter to how attractive a programming environment a language provides, little of it is relevant to the core language. Gnu Classpath provides a nearly adequate basis for implementing Clojure on LLVM for my purposes, although perhaps not for johnw's
I had just run into VMKit myself as well, and I'm curious. It says it doesn't support "mixed interpretation/compilation": is that an architectural limitation, or unfinished work? It certainly looks interesting.
Postscript: ncm wrote:
I find it a little bit ironic, under the circumstances, for Haskell to be a pig, considering that the Haskell/Caml family of languages has, potentially, much less use for garbage collection than other functional languages, and could, with (what are really quite) minor language changes, live with runtime support no larger than C++'s.I'd like to believe this, but I don't see how this can be true. The dominant programming paradigm for Haskell, in particular, encourages heavy use of higher-order functions, which, at least according to the obvious interpretation, requires very heavy heap usage for allocation of closures. Techniques such as substituting region inference for GC might improve predictability of resource usage, but they seem to do so at the expense of efficiency; perhaps FP allows one to choose which runtime costs one has, provided they are heavy.