• JVM
    March 25, 2009

PyCon VM summit

John Rose
I was at the PyCon VM summit; it was great! There were about 20 talks (in the 10-20 minute range). Since "Sun" comes late in the alphabet, I had the pleasure of watching my fellow summiteers go first. When everybody was good and tired, I gave a presentation on the Da Vinci Machine Project. Here are some notes on a few of the other talks...

Microsoft .NET DLR: Rolling along nicely; they have fixed a number of performance problems since last year, and have matured their dynamic language support, as showcased in IronPython. Call-site caching is the name of the game this year, on DLR, the JVM (that's what invokedynamic does), and the rush of new high-performance JavaScript implementations. DLR folks also enjoy working with .NET expression trees, very rich run-time type information, reified generics, iterators (generator-like things). They aren't fooling with continuations, at least this year. They have apparently sped up tail-call, which used to be much slower than regular calls.

There is a fork of CPython at Google called "Unladen Swallow" (I can't stop thinking of how Pythons eat; aghh). Its goal is to get 5x speedup in one year, by the application of google-osity to pythonic performance problems. BTW, like Ruby, new Python implementations are challenged by the need to either rewrite or cope with existing giant libraries written in C. This would be a huge problem for Java, as the JVM has all sorts of strong execution invariants that C code would break, were it not for the firewall of JNI.

JRuby (yes, Charlie and Tom were there) is able to punt some of its performance problems to the JVM's JIT, GC, and general multiprocessor support. Their challenge is reimplementing Ruby without a specification; this also is a characteristic problem of the new crop of languages. (I'm now even more grateful for the excellent early work on specs. in the Java ecosystem.) They are running a Ruby interpreter, which then JITs (after a short warmup) to JVM bytecodes, which (they hope) the JVM eventually JITs to machine code. Like Python (and Java) they need a foreign function interface which is fast and easy to use.

Meanwhile, Jython has very simple bytecode translation; hopefully both they and JRuby will make more use of invokedynamic by JavaOne.

PyPy continues to be a fascinating exercise in bootstrapping. Their toolchain generates, from a factored group of executable specifications, the whole Python interpreter and GC, which makes it easy (when it works) to fold in read/write barriers, security checks, trace JITs, and other exotica. They run fully stackless. (A number of people talked about stackless execution. Part of the attraction is easy support for generators and perhaps other coroutines; part of the attraction is an inverse repulsion from the C stack, which is hard to control.)

Rubinius is a reimplementation of Python Ruby in the style of Smalltalk 80, including dead-simple bytecodes and those cute backtracking primitives. (ST80 primitives can fail on arguments they don't want to handle, causing the VM to run the associated bytecoded method.) It also is stackless. It has an "Immix" GC (regional, kind of like OpenJDK's G1). As with a number of these systems, a JIT seems imminent... though JITs always take longer.

There were other cool VMs, including Spider Monkey (trace-based from Mozilla), Parrot (continuation-based stackless), MagLev, and Factor. After the presentations, we hung around the room all day and talked ourselves until exhaustion, then went and ate and talked more. It was a memorable day!

Join the discussion

Comments ( 2 )
  • Slava Pestov Thursday, March 26, 2009

    Hi John, I wanted to ask you a question yesterday but I forgot; how does HotSpot keep track of ICs that need to be invalidated when methods are (re)defined? Is there anything fancier than a global list of all call sites grouped by method name?

  • John Rose Tuesday, March 31, 2009

    Slava: Yes, the JVM has elaborate dependency tracking, and can patch both the caller and callee of an IC, depending on the needs of the changing program.

    If a single method is invalidated, it can be patched to prevent it ever being entered again, and even patched (more thoroughly) to prevent pending continuations from ever returning to it.

    There is a global data structure for tracking dependencies of caller code on callees. It is indexed by class, which is somewhat better than a flat global list. The class index is the upper bound of the region of the class hierarchy where changes might affect the validity of the dependent machine code.

    All this may be found in the Hotspot OpenJDK source code.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.