Dynamic Languages in the JVM - Discussion Notes from the CommunityOne RedMonk Unconference

Discussion led by Charles Nutter, Tom Enebo, Ola Bini and Jim Rose who is leading the JSR to update the JVM instruction set to enable them to work better (JSR-292).

Conversation went onto whether dynamic languages on the JVM are needed (asked by an IBM representative) The overwhelming consensus was “yes”. It seemed to me that he / IBM don't think this dynamic thing was as important as the rest of the room. That could however just be my interpretation. People chipped in to say that while the majority of their development is pure Java at the moment, this is changing from the edges in some places or in greenfield sites. The fact that some alternate VM languages are less performant (ie. JRuby) is less important at the moment than the fact that to your IT Ops guys it looks like any other java app – in the case of JRuby, just a war. This is big. Deployment is important. If I can run it on what I have then that lowers the barrier to entry. That point was made very strongly.

Then discussion went on to calling Java resources from non-Java, JVM based languages. This is where the JCP can play the group agreed. However the JCP should not try and crash in on the language communities themselves. Charles stressed that they were not doing this with Ruby – in the same way they have a v. good relationship with Matz and are helping with input to Ruby 2.0. They plan is for JRuby to be an alternative Ruby VM like any other. The same is true of the Jython community and others. Discussion then circled around whether the JCP should come up with a plan for how these many languages should interoperate. The answer was a definite “no”. That would be bad all agreed. A Scala developer from Circle Share said that it is the community members from each language who should do that. The JVM (as designed by the JCP) should should however help support the languages with things like invokeDynamic in the instruction set and let the higher level things take care of themselves.

More detail was then provided about what invokeDynamic is and why it is useful. Dynamic languages make it very difficult to figure out what the invocation sites are for your function calls. This is why scheme has only 5 and smalltalk only 1 (“methodsite”). “InvokeDynamic” is in one respect a slogan for this generic, late bound message sending.

There are some issues with this on the JVM we were told:

1. Will JIT optimise it correctly / well?

2. If you do optimise your invoke site, what does your path to it then look like:

• Do you have a fast execution path (with a guard to catch situations when you (the JVM) are wrong)?

• Or do you have slow execution path (in case something changes on the fast path) which you hope never changes?

However, the Hotspot JVM has lots of tricks to hedge bets on the fast path. This is not only a Java thing and all JVM languages can take advantage of it. However there is a missing piece in the bytecode which allows you to specify a more dynamic message site.

Microsoft have achieved this in the CLR with the “Dynamic Language Runtime” which is a set of bits on top of the standard CLR. This type of solution is already available in Java but invokeDynamic would allow other JVM languages to benefit.

At this point we ran out of time. One participant suggested that we set up a google group to continue this discussion. Charles Nutter offered to do this. To participate, send him and email (charles dot nutter at sun dot com) and refer to this session in the title.