I spent last week at the JVM Language Summit, a small conference focused on non-Java JVM-based languages.  It was populated almost solely by either JVM implementors or bytecodes-are-my-new-assembler types.  It was a very fun & geeky conference for me; some of the best technical discussions I’ve had in a long time.  My favorite philosophical talk was definitely Erik Meijer talking about Fundamentalist Functional Programming.  In the end, he’s all for non-pure side-effecting programming BUT he wants the type system to “stop lying” about side-effects.  We both agreed that we’d love to see a functional programming language which had types for side-effects (e.g. Haskell’s IO “sin bin”), but with more elaborate side-effects.  I.e., if I’m writing my program with few-to-none side effects I might want to track them exactly (e.g. this function has type ‘side-effects field _code’) but if I call into the Swing or AWT libs I might want a type like ‘side-effects all Java variables’.

My favorite techy/JVM talk was Bernd’s Maxine VM.   I think he’s got a really good nearly pure-Java layer figured out for generating ASM code.  You want something that looks like running plain Java code (and does field reads & writes) that guaranteed must inline down to where the JIT turns it into atomic machine code loads & stores.  He’s missing lots & lots of major features (e.g. good JIT, good GC) but the framework looks nice.  If we ever are to get a true JVM-in-JVM (and skip bootstrapping your JVM via a C++ compiler which is what HotSpot does), I think Maxine has the best chance.

Most desired JVM feature: invokedynamic; this would cut huge chunks of evil code out of most JVM-based languages (but not Clojure & JPC, both of which target 1.5 JVMs more closely).
Most needed JVM feature without changing the spec: a trivial Escape Analysis suitable for dealing with endless Fixnum/BigNum math.  Most of these non-Java JVM languages do fixnum/bignum math (automatically overflowing fixed-int math into bignums) – which means every trivial bit of integer math creates a new Fixnum object.

I showed off Azul’s RTPM and got lots of oooo’s and aahhhh’s.  I convinced lots of people to sign up for academic accounts mostly for access to RTPM.  I was able to quickly diagnose a big problem w/JRuby (failure to inline a key trampoline, masked by +PrintInlining lying), and also got 20% speedup on the ASM library – the core bytecode parsing library in widespread use.

My own talk was well received:

Brian Goetz wrote:

your talk was both the most popular and highest rated, according to the comment cards. 

The slides are here although the postscript conversion mostly screwed up my transparent ovals.  Mostly I ran this trivial program on Azul’s JVM using these languages: Scala, Clojure, Jython, JRuby, JavaScript/Rhino, & JPC. I profiled them using RTPM and report on the profiling.  See the slides for the in-depth discussion.  3 things popped out:

1. Clojure, JRuby, Jython, Javascript/Rhino all using fixnum/bignums for every trivial piece of math – which ends up allocating new FixNums for each simple integer operation. A major fix for this would be to implement the simplest possible Escape-Analysis. You’ll still end up with the overflow checks but the major cost here is the Fixnum allocation (and NOT the GC costs; the fixnums trivally die in the young-gen; direct GC costs are quite modest).
2. JRuby was thinking that a key trampoline function was inlining – and it wasn’t.  See the slides for details, but hopefully we’ll see a JRuby with a substantial performance boost soon.
3. I ran Clojure’s STM Traveling Salesman Problem using 600 worker ‘ants’ to optimize the path.  It ran straight-up without a hitch, no tweaks – and with great scaling (it did allocate about 20Gig/sec on a 200Gig heap but this is easy for an Azul box to cope with).  There may be hope for STM’s after all – IF the set of STM variables is limited to a handful of named shared variables, and not for dusty-desks that must assume all-is-shared.

Cliff