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).

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

-- John

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.

Best regards,
-- John Rose

Hi John

Thanks for sharing the update.

Ready means "fully specified"? The EG has to produce an RI, correct?
If so, would that be MLVM patches to HotSpot?

I was surprised to read this--I'd thought that tail recursion was
higher on people's list than continuations...was there any discussion
of TCO?

Also, I'd read from a couple of language implementors (Charles N among
them, in http://headius.blogspot.com/2008/05/power-of-jvm.html, as
well as the maintainer of Pnuts, in
http://www.jroller.com/tomatsu/entry/i_don_t_need_invokedynamic) that
invokedynamic wouldn't help them much--note I don't want to put words
in the mouths of the respective speakers, I've just read this POV a
handful of times. Does the EG still believe this is useful? Perhaps
"it seemed like a good idea at the time"...?

Thanks again
Patrick

On May 7, 2008, at 12:57 PM, Patrick Wright wrote:

JCP requires a spec. and an RI, yes.  And they are distinct; see this  
point:

But "ready" also means the points referred to in:

Yes, that is where the RI will be, until it integrates up into JDK7.

I believe we discussed that briefly during the hour.  That question  
was sort of a straw poll:  It gives what was uppermost in peoples'  
mind during the meeting.  For a fuller list, see the mlvm subprojects  
page on our OpenJDK site.  TCO is on that longer list.  Will the EG  
standardize on it?  It depends on what the community says about the  
relative priority of the various features we are looking at, who is  
making proof of concepts, and how the JVM vendors (plural!) feel the  
customer demand, balanced against their difficulty of implementation.

Charlie can respond to that without me, but I'll say (a) I advised  
him on the optimizations in that blog, and (b) he and I both believe  
that invokedynamic will take those optimizations to the next level.

Just because JRuby (and soon other dynamic languages) is now faster  
does not mean their aspirations for speed have ended.  Please refer  
back to the minutes again:

That's a 2006 blog and several things have changed.  Two years ago,  
dynlang people were compiling lots of goo between their language and  
the JVM.  Over time they have reduced the overheads they can control,  
and some of them are hitting walls which the JVM should properly  
address.  Perhaps other blog entries of Charlie's discuss this...

The language implementor's choice is always roll your own vs. reuse a  
platform.  In a number of ways, the JVM platform is getting upleveled  
for dynamic languages, providing more options for reuse.  The JVM  
extensions we are aiming at will improve the quality of things like  
MOPs.

That's always a risk, isn't it?  But the point of the meeting  
yesterday is, yes, the EG still believes it is useful.

The JVM vendors worry rightly about adding features nobody will  
really use.  We think this one will get used.

-- John

John

Thanks for the thorough response.

Best regards
Patrick