JVM Language Summit
September 29, 2008

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

Category: Web/Tech | | TrackBack (0)

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83451bd7669e2010534e5f480970c

Listed below are links to weblogs that reference JVM Language Summit:

 

Comments

Hi,

The link to the slides is broken. It contains a trailing colon, but even after removing that it does not work for me.

Ismael

Posted by: Ismael Juma | Sep 29, 2008 5:35:05 PM

 

Hi,

The overlay on the right hand side of the page that has a list of all posts is hovering over the article on firefox 3.0.

Karl

Posted by: Karl | Sep 29, 2008 5:45:46 PM

 

Fixed the colon. The slide URL works for me. If it's still busted for you maybe you need to enable cookies or something like that?

The Firefox 3.0 issue I've already complained about.

Thanks!
Cliff

Posted by: Cliff Click | Sep 29, 2008 5:59:54 PM

 

Looks like your layout is broken. The side bar covers the text. Checked on Chrome, FF 3, IE 6.

Posted by: Chris Thiessen | Sep 29, 2008 8:40:16 PM

 

Interesting post.

The firefox issue is annoying but fairly trivial to fix with the firebug plugin - just hide the container div (add visibility:hidden; to #sidebody)

Posted by: Bruce Ritchie | Sep 29, 2008 9:12:05 PM

 

Hi Cliff,

Thanks for fixing the link. It works now (not sure why it didn't when I manually removed the colon). Interesting slides, particularly the concurrency aspects. It would have been interesting to see results for languages other than Clojure, but time has that habit of getting in the way. ;)

Ismael

Posted by: Ismael Juma | Sep 29, 2008 9:15:38 PM

 

I'm not doing Clojure enough justice here. You don't have to have fixnum/bignum inflation if you don't want it; then Clojure spits out bytecodes that look really nice. The purely functional data-structures also look really nice; and the STM scaled surprisingly well. I definitely need to do some coding with it.

And yes, I know the layout is busted but apparently the layout-miester isn't reading email this late at nite. :-)

Cliff

Posted by: Cliff Click | Sep 29, 2008 9:54:59 PM

 

for those of us who couldn't make it (despite working next door to you; time, not space, was my problem), could you elaborate on "final fields cost mfence" and "e.g. getting around Integer.valueOf(i) caching" from slide 8?

Posted by: Elliott Hughes | Sep 29, 2008 10:08:43 PM

 

Sure... making a 'new Integer' involves setting a java 'final' field - and that has JMM semantics. On different platforms you need a 'mfence' of some kind; which kind varies by platform. Certainly the HotSpot of some years ago plunked down a fence after setting any final fields (and before the object escapes). On X86's of the last era I looked at them, such a fence cost roughly the same as a cache-miss.

On the Integer.valueOf() caching - values from -128 to +127 or so are cached, and calling valueOf() will return a value loaded from an array instead of making a new object. If the JIT is to use Escape Analysis to remove a dead allocation of a new Integer - it will have to "see through" the inlined code of valueOf() - including the loading of a strange unknown Integer from some mysterious array if the input is +/-128 or removing the dead new Integer() otherwise.

i.e., if Escape Analysis is turned on & working, then the new Integer cache is pretty much worse than no cache for these new languages. Since EA isn't here yet (really) the cache still has a purpose.

Cliff

Posted by: Cliff Click | Sep 29, 2008 10:15:11 PM

 

// On X86's of the last era I looked at them, such a fence cost
// roughly the same as a cache-miss.

interesting. i didn't check with gdb(1), but adding/removing "final" from my IntegerValue class (basically the same as Integer, but also serving as home to my integer methods) only seems to make a small difference. without "final" seems to be about 55s, with "final" 57s.

// i.e., if Escape Analysis is turned on & working, then the new
// Integer cache is pretty much worse than no cache

ah, i see. out of context i thought there was something scary about Integer.valueOf right now. that's a good point, though, and something we'll [hopefully] have to watch out for in the future.

Posted by: Elliott Hughes | Sep 29, 2008 10:29:10 PM

 

Ben Lippmeier's Disciple (http://www.haskell.org/haskellwiki/DDC) has some of the side effect typing that you're interested in, if I understand you correctly.

If you're still interested in implementations of 'simple' in other JVM languages, I have one in CAL (http://openquark.org) -- if you'd like an executable jar email me.

Interesting data point on Clojure's STM!

Posted by: Tom Davies | Sep 30, 2008 4:50:05 AM

 

DDC looks very interesting, but I don't speak the lingo! This *looks* like what I'm looking for, but I clearly have a lot of research reading before I can really tell.

Maybe I should ask Ben to provide a DDC-style type-system wrapper over Clojure. :-)

Cliff

Posted by: Cliff Click | Sep 30, 2008 9:24:32 AM

 

Hi Cliff,
I noticed the Jikes RVM a while back (www.jikesrvm.org). It sounds like their goals are similar. Are you aware of what their differences might be?

Thanks,
Jim

Posted by: Jim Bethancourt | Sep 30, 2008 2:04:55 PM

 

I think Jikes' goals have always been to be a great research VM, a goal they achieved in retrospect. DDC looks like a pure research project into a better side-effect typing system. Or are you thinking of the differences between Jikes & the Azul VM? We're a (heavily modified) port of HotSpot - which has always been a production VM - meaning it's fast & stable & complete, but a pain-in-the-neck to do research with.

Cliff

Posted by: Cliff Click | Sep 30, 2008 2:25:28 PM

 

I think Jim Bethancourt wanted to compare Jikes RVM with Sun's Maxine - both are research-oriented JVM's written in Java. Also, you say "3 things popped out:", but the article then has just point "1.", where are 2. and 3.?

Posted by: Blaisorblade | Oct 6, 2008 4:33:25 PM

 

oops - fixed.

Posted by: Cliff Click | Oct 7, 2008 7:03:24 PM

 

Somebody else trying Scala on Azul:

http://blog.jayway.com/2008/10/20/azul/

Posted by: Cliff Click | Oct 21, 2008 6:28:38 AM

 

Post a comment