The invokedynamic in Scala

On Mon, Oct 11, 2010 at 12:13 PM, Leonid Mesnik <leonid.mesnik@gmail.com> wrote:

Hi 
Does anybody about using of 'invokedynamic' JVM instructions in Scala?I am wondering whether any exist development version or any plans about this instruction in Scala?

Invokedynamic can make dispatch on structural Scala types faster, so it makes sense to use it. On the other hand, Scala can still run on JDK 1.5 VMs, so it will be a while until we are in a position to demand to run on Java 7 by default. We'll probably use a -target switch to make optional use of JDK 7 features including invokedynamic once Java 7 is out.

Cheers

 -- Martin

On Mon, Oct 11, 2010 at 12:13 PM, Leonid Mesnik <leonid.mesnik@gmail.com> wrote:

Hi 
Does anybody about using of 'invokedynamic' JVM instructions in Scala?I am wondering whether any exist development version or any plans about this instruction in Scala?

I had a quick look at the invokedynamic business, and I couldn't find a specification against which to work. The JSR seems dead (last activity in 2008), the wiki pages on the da vinci project also look outdated. 
I had a stab at implementing it (in fact, there is some code in the backend for that purpose) in late 2008, but back then it was largely unusable for us: there was no (easy) way to uninstall a method handle once it was installed in an invokedynamic. One needs to generate bytecode at runtime to test the actual receiver type, and re-install the handle if the receiver changed. The initial support for that was very poor, so I gave up. I wouldn't invest too much time again unless I can find a specification and a reference implementation (I might have missed them, I only googled for around 5 minutes). Do you know more about the current status?
cheers,iulian 

Thank you,Leonid

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

On Tue, Oct 12, 2010 at 9:49 AM, iulian dragos wrote:
> I had a quick look at the invokedynamic business, and I couldn't find a
> specification against which to work. The JSR seems dead (last activity in
> 2008)

The JSR is certainly not dead, John has been sending emails to the
MLVM list discussing issues they're tackling. Also, much of the code
has been integrated into the OpenJDK's jdk7 repository, which makes it
easier to play with it these days. John posted a link to the javadoc
at the end of March 2010:

http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/

Not sure if it gets updated regularly or if it's just a snapshot though.

Best,
Ismael

On Tue, Oct 12, 2010 at 11:38 AM, Ismael Juma <mlists@juma.me.uk> wrote:

On Tue, Oct 12, 2010 at 9:49 AM, iulian dragos <iulian.dragos@epfl.ch> wrote:
> I had a quick look at the invokedynamic business, and I couldn't find a
> specification against which to work. The JSR seems dead (last activity in
> 2008)

The JSR is certainly not dead, John has been sending emails to the
MLVM list discussing issues they're tackling. Also, much of the code
has been integrated into the OpenJDK's jdk7 repository, which makes it
easier to play with it these days. John posted a link to the javadoc
at the end of March 2010:

http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/
 

Not sure if it gets updated regularly or if it's just a snapshot though.

Thanks! It is indeed more fleshed out than 2 years ago, but it still seems very early. The JSR may not be dead, but it is a bit disappointing that there is no new document in more than 2 years. We'll look at it again when JDK7 gets closer to a release.
iulian 

Best,
Ismael

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

On Tue, Oct 12, 2010 at 12:32 PM, iulian dragos wrote:
> Thanks! It is indeed more fleshed out than 2 years ago, but it still seems
> very early. The JSR may not be dead, but it is a bit disappointing that
> there is no new document in more than 2 years. We'll look at it again when
> JDK7 gets closer to a release.

It would certainly be nice if things could be done faster, but it's
not like they have not been doing anything for those 2 years. JIT
support for x86, x86_64 and sparc has been implemented in OpenJDK
during that period and they've been refining the spec based on
feedback from language implementers and what they're learning during
the implementation. It is important for the design to enable the
performance goals of the project and it takes time to verify this.
Finally, Christian Thalinger is currently working on the bits
necessary for invokedynamic and method handles to be enabled by
default in OpenJDK7 (some work is needed for it to work with escape
analysis and compressed oops)[1].

By the way, there are a couple of papers that may be interesting:

Optimizing Invokedynamic by Christian Thalinger and John Rose,
http://blogs.sun.com/jrose/resource/pres/201009-PPPJ.pdf
Towards Performance Measurements for the Java Virtual Machine’s
invokedynamic by Chanwit Kaewkasi,
http://dl.dropbox.com/u/381580/vmil10_kaewkasi_revised.pdf

Best,
Ismael

[1] http://bugs.sun.com/view_bug.do?bug_id=6817525

On Tue, Oct 12, 2010 at 1:50 PM, Ismael Juma <mlists@juma.me.uk> wrote:

On Tue, Oct 12, 2010 at 12:32 PM, iulian dragos <iulian.dragos@epfl.ch> wrote:
> Thanks! It is indeed more fleshed out than 2 years ago, but it still seems
> very early. The JSR may not be dead, but it is a bit disappointing that
> there is no new document in more than 2 years. We'll look at it again when
> JDK7 gets closer to a release.

It would certainly be nice if things could be done faster, but it's
not like they have not been doing anything for those 2 years. JIT
support for x86, x86_64 and sparc has been implemented in OpenJDK
during that period and they've been refining the spec based on
feedback from language implementers and what they're learning during
the implementation. It is important for the design to enable the
performance goals of the project and it takes time to verify this.
Finally, Christian Thalinger is currently working on the bits
necessary for invokedynamic and method handles to be enabled by
default in OpenJDK7 (some work is needed for it to work with escape
analysis and compressed oops)[1].

I'm sorry if my email sounded like I implied they're slacking off, that was surely not my intention. I know it's difficult and takes time. However, invokedynamic is not central for Scala performance: structural types are relatively uncommon, and it's not yet clear how much faster 'invokedynamic' is going to be. So I don't think this will be high priority until there is a clear specification. Of course, I speak only for myself, others may be more inclined to try it. I can then explain what has been done/what code still exists in the compiler.

By the way, there are a couple of papers that may be interesting:

Optimizing Invokedynamic by Christian Thalinger and John Rose,
http://blogs.sun.com/jrose/resource/pres/201009-PPPJ.pdf
Towards Performance Measurements for the Java Virtual Machine’s
invokedynamic by Chanwit Kaewkasi,
http://dl.dropbox.com/u/381580/vmil10_kaewkasi_revised.pdf

Thanks, I'll have a look!
iulian 

Best,
Ismael

[1] http://bugs.sun.com/view_bug.do?bug_id=6817525

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

On Tue, Oct 12, 2010 at 3:00 PM, iulian dragos <iulian.dragos@epfl.ch> wrote:

However, invokedynamic is not central for Scala performance: structural types are relatively uncommon, and it's not yet clear how much faster 'invokedynamic' is going to be. So I don't think this will be high priority until there is a clear specification.

I agree. Personally, I am more interested in method handles as a way of implementing anonymous functions, but it's also probably too early to investigate that. Better let the lambda project (from OpenJDK) guys play with it first.
Best,Ismael

On Tue, Oct 12, 2010 at 7:32 AM, iulian dragos <iulian.dragos@epfl.ch> wrote:

Thanks! It is indeed more fleshed out than 2 years ago, but it still seems very early. The JSR may not be dead, but it is a bit disappointing that there is no new document in more than 2 years. We'll look at it again when JDK7 gets closer to a release.

If you are worried about the *spec* of invokedynamic, then now is a really great time to speak up. If you wait until JDK7 is close to release, the spec is going to be pretty well frozen and impossible to change. If you say something now, on the JSR mailing lists, then I'm sure they'll be eager to make the necessary adjustments.
Scala is actually a relatively easy case compared to Python or Ruby. At least with Scala, the method tables are immutable for a given object. They're even immutable for a given class.
-Lex

Thank you all for answers.
They really help me. 
2010/10/12 Lex Spoon <lex@lexspoon.org>

On Tue, Oct 12, 2010 at 7:32 AM, iulian dragos <iulian.dragos@epfl.ch> wrote:

Thanks! It is indeed more fleshed out than 2 years ago, but it still seems very early. The JSR may not be dead, but it is a bit disappointing that there is no new document in more than 2 years. We'll look at it again when JDK7 gets closer to a release.

If you are worried about the *spec* of invokedynamic, then now is a really great time to speak up. If you wait until JDK7 is close to release, the spec is going to be pretty well frozen and impossible to change. If you say something now, on the JSR mailing lists, then I'm sure they'll be eager to make the necessary adjustments.
Scala is actually a relatively easy case compared to Python or Ruby. At least with Scala, the method tables are immutable for a given object. They're even immutable for a given class.
-Lex

On Tue, Oct 12, 2010 at 3:00 PM, iulian dragos wrote:
> Thanks, I'll have a look!

By the way, John Rose posted a message today about some changes based
on likely requirements of Project Lambda and Summit discussions and
asked for feedback from language implementors:

http://article.gmane.org/gmane.comp.java.openjdk.mlvm.devel/1992

Best,
Ismael