JSR 292 EG meeting at JavaOne (summary)
John Rose
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
Patrick Wright
Thanks for sharing the update.
> * When the final spec. is presented, it will include whichever
> features are ready.
Ready means "fully specified"? The EG has to produce an RI, correct?
If so, would that be MLVM patches to HotSpot?
> What do language implementors want?
> * Short list: Invokedynamic, method handles, continuations.
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
John Rose
>> * When the final spec. is presented, it will include whichever
>> features are ready.
>
> Ready means "fully specified"? The EG has to produce an RI, correct?
JCP requires a spec. and an RI, yes. And they are distinct; see this
point:
>> * the EG produces specification only, not code (JVM implementors
>> insist on this!)
But "ready" also means the points referred to in:
>> * Adoption of JSR 292 features depends on
> If so, would that be MLVM patches to HotSpot?
Yes, that is where the RI will be, until it integrates up into JDK7.
>> What do language implementors want?
>> * Short list: Invokedynamic, method handles, continuations.
>
> 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?
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.
> 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
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:
>> Do dynamic languages really need performance
> , 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
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...
> in the mouths of the respective speakers, I've just read this POV a
> handful of times.
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.
> Does the EG still believe this is useful? Perhaps
> "it seemed like a good idea at the time"...?
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
Patrick Wright
Thanks for the thorough response.
Best regards
Patrick