JSR 292 meeting at JavaOne 2008

Hello, JSR 292 observers and language implementors!

The JSR 292 Expert Group met today at JavaOne.

There were representatives from three major JVMs and two dynamic languages (Groovy, Jython).

Here are some of my notes from that meeting. I hope you find them interesting.

The EDR for invokedynamic has been given to the JCP. It is a milestone!

Grouping of JSR 292 features

• Current EDR is invokedynamic only (with method handles required for support)
• Adjustments during the 90-day EDR period will not add unrelated features
• Other features are likely (class modification of some sort) but will be independent
• When the final spec. is presented, it will include whichever features are ready.

Relation to Da Vinci Machine Project http://openjdk.java.net/projects/mlvm/

• interesting experiments with anonymous classes, interface injection, continuations, etc.
• JSR 292 EG controls whether these become an EDR on the way to standardization
• community controls whether they get tried out
• the EG produces specification only, not code (JVM implementors insist on this!)

Adoption of JSR 292 features depends on...

• Demonstrated usefulness to language implementors (must integrate & demo. a POC)* *
• Optimizability by JVM implementors (must think it through to the instruction level)

We will do this work this summer and reconvene (with more people) at the JVM Language Summit.

Technical Discussion of Draft Design

JVM to language implementors: Do dynamic languages really need performance?

• As long as dynamic languages are the 5% scripting portion of an app., they do not.
• If they get parity with Java, they can grow from 5% to 50%.
• If they get enough performance to beat the original C implem., they can become platform of choice.
• For any given language (e.g., Python) if the pure (non-C) libraries get parity with C, lots of things get easier.

What do language implementors want?

• Short list: Invokedynamic, method handles, continuations.
• JVM implementors are nervous about continuations (Da Vinci M. experiments ongoing)

Method handles and invokedynamic

• Method handles look good to all parties; a nicely balanced design.
• They give direct (JVM-native, non-reflective) access from caller to a method.
• Multiple use cases, for multiple languages. (Discussed in detail for Jython and Groovy.)
• The JVM managed state for invokedynamic is one word only, a single method handle. Simple for JVMs.
• Caching & receiver guard logic is responsibility of language implementors.

We discussed a few JVM-centric questions about method handles and invokedynamic.