invokedynamic on the JVM and JavaScript as a Compilation Target
The JVM is now a compilation target for many dynamic languages. The implementers of those dynamic languages have been waiting for invokedynamic so they can make their dynamic languages compile to more efficient JVM byte code. Sun seems to have caught on that people want to use the JVM but not use Java and Sun seems to be looking at ways to accommodate the compilation of these dynamic languages. Microsoft's .NET CLR+DLR is ahead of Sun and has implemented features for efficient dynamic language compilation. Developers have made it clear that even if they are locked into the platform, they are going to still use their language of choice.
The same is happening in the browser. Developers are compiling many languages down to JavaScript ("they byte code of the browser"). GWT and Cappuccino are two well know examples. These projects are overruling the idea that they must write in JavaScript to create browser apps. They don't have to wait for the ECMAScript committee to standardize methodMissing, for browsers to implement it and for old browsers to disappear. Ten years? No way! They have methodMissing now!!
Is it inevitable that browser makers and/or the ECMAScript standard group will add features to JavaScript specifically to make it a better compilation target or expose actual byte code? By making JavaScript engines faster, browser makers have already started. Should the effort to make the browser a better compilation target be encouraged and expedited so the long drawn out "eventually" can come sooner?
Comments
Have something to write? Comment on this article.
Charles,
Yes it was the DLR that I was meaning. At least Microsoft had made an attempt at helping those implementing dynamic languages a while ago.
Have something to write? Comment on this article.
The CLR does not actually contain any special features that make it a better target for dynamic languages. That's done at the IL/code/compiler level by the DLR, which largely works around optimizations the CLR doesn't do itself. In essence, DLR's execution-time features exist precisely *because* CLR is so poor at optimizing dynamic dispatch on its own.
DLR does in theory make it easier to implement languages at first, since it includes all sorts of tooling goodies useful during those early stages. But as far as performance goes, DLR+CLR has not proven to be any better at optimizing performance than the JVM, and in truth it may actually be worse (e.g. when comparing IronPython to C Python with all Python features enabled, since IP disables some for performance).
What I'd really like to see is someone pick up Rhino (JS for the JVM) and make it take advantage of what we've learned implementing JRuby as well as new features like invokedynamic. I dare say it would give the custom JS VMs a serious run for their money.