• JVM
    September 23, 2010

JavaOne in 2010

John Rose
This week I gave two talks at JavaOne. Here are my slides.

On Monday Brian Goetz and I talked (again, as in 2009) about the future of the JVM in One VM, Many Languages. The room was full of attentive listeners. I gave an update on the theory and practice of invokedynamic and JSR 292.

On Tuesday evening, I talked about an experiment I did last December combining Rhino with invokedynamic. The talk was Great Thundering Rhinos! (an expedition into JavaScript optimization). That time, the hour was late and the room was not at all full. But the listeners were still attentive. (Thanks, guys!)

For the record, the current draft of invokedynamic (soon to become final) is always available here:


Introduction to One VM:

The Java Virtual Machine (JVM) has, in large part, been the engine behind the success of the Java programming language. The JVM is undergoing a transformation: to become a Universal VM. In years to come, it will power the success of other languages too.

Introduction to Thundering Rhinos:

JavaScript presents difficult implementation obstacles. JDK 7 provides an excellent toolkit for implementors.
This is a case study of optimizing Rhino with invokedynamic.

The above links are to HTML renderings of the presentations. PDF renderings are also available for One VM and Thundering Rhinos in the HTML presentation of the first part of this sentence.

Join the discussion

Comments ( 1 )
  • Carl Friedrich Bolz Sunday, September 26, 2010

    The parallel evolution of VMs is as usual impressive. PyPy's Python interpreter has a very similar approach to implementing user-defined instances. The problem to be solved is similar, it is possible to add arbitrary attributes to Python instances at any point. The Python VM thus also has uses to describe the layout of the individual instance and also uses differently-sized VM-level classes to represent objects (the equivalent of Struct4 in the presentation). The extension is not actually its own field, but the Object array will be put into the last property field, if necessary.

    I expect that the resulting assembler code that the JIT produces in the end is also quite similar, the checks that are described on slide 28 are very similar to those that PyPy does. The differences are that we don't need to do Test 1.

    I was wondering what sort of statistics Rhino is keeping to predict the final number of properties? Does it track final object sizes per allocation site or something?

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