On May 7, 2008, at 12:57 PM, Patrick Wright wrote:
>> * 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
>> * 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.
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...
> 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
> 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.