JavaOne in 2010

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:
http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm

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.

Comments:

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?

Posted by Carl Friedrich Bolz on September 26, 2010 at 12:52 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

John R. Rose

Java maven, HotSpot developer, Mac user, Scheme refugee.

Once Sun and present Oracle engineer.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today