Dynamic Languages on the CLR and JVM

Posted by Charles Humble on Feb 12, 2008

Sections

Development

Topics

Ruby ,

.NET ,

Dynamic Languages ,

Java

Tags

IronRuby ,

IronPython ,

Jython ,

JRuby

A number of Sun's engineers recently attended the Lang .NET Symposium, with John Rose and Charles Nutter introducing Sun's Da Vinci Machine project to the largely .NET audience. This project has superficial similarities to Microsoft's Dynamic Language Runtime (DLR) in that both projects aim to improve support for dynamic languages on their respective Virtual Machines. However they take substantially different approaches to the problem.

Charles Nutter writes:  largely based on Jim Hugunin's work on IronPython, the DLR is a set of libraries and tools designed to make it easier to implement dynamic languages on the .NET CLR. The DLR provides facilities for compiler and interpreter generation (via language-agnostic expression trees), fast dynamic invocation (via self-updating dynamic call sites), cross-language method dispatch and type system support. The majority of the work for the DLR is done as a set of libraries on top of the DLR with few changes made to the underlying CLR to accommodate them.

The scope of the Da Vinci project is broader in that it targets both dynamic and functional languages. Building on JSR-292, it is an experimental branch of Sun's reference JVM which will prototype a number of extensions to that Virtual Machine so that it can run non-Java languages efficiently with a performance level comparable to that of Java itself. The major sub-project is the implementation of dynamic invocation, which provides a mechanism by which a language compiler can compile a non-Java call site, with a language-specific handler determining call site linkage at runtime. Linkage can be sensitive to dynamic argument types, and can be updated or revoked over time. There are also a number of other smaller sub-projects including adding support for tail calls and tail recursion (via a new tailcall bytecode prefix), and tuples (using a new tagged tuple signature string). The intention is that at least some capabilities of the Da Vinci Machine will form part of the Java SE 7 Virtual Machine specification.

In a blog post about the visit John Rose talked about the growing interest in new programming languages on the JVM and CLR:

"The DLR (with IronPython and IronRuby) is another evidence that we are in some sort of renaissance or resurgence of programming language design. For some reason, people are inventing programming languages again in a big way, expecting to get audiences, and sometimes getting them. I think the “some reason” is a combination of better tools and higher-level runtimes and cheaper CPU cycles and the open source movement."

Rose also discusses the similarities between the Da Vinci Machine and the DLR:

[There is] a striking case of parallel evolution between the DLR over the CLR on one hand and the Da Vinci Machine over the JVM on the other side... In my work on JVM dynamic invocation, I knew I was applying tried and true ideas from Smalltalk, Self, and CLOS, but I was encouraged to find that a colleague (and competitor) had been busy proving the practicality of those ideas."

Since the DLR is implemented with minimal changes to the CLR itself, much of the work that has gone in to the DLR is focused on getting better performance out of the CLR for dynamic languages. This, Rose argues, isn't a necessity in the Java world because the JVM JIT already supports considerably more aggressive optimization techniques. Charles Nutter makes similar observations in his blog post on the trip:

"The CLR, on the other hand, does not (yet) have the same level of dynamic optimization that the JVM does. Specifically, it does not currently support deoptimizing code that has already been JITed, and it does not always (occasionally? rarely?) include type information into its consideration of how to optimize code. So for dynamic languages to perform well, you simply have to do additional work. You don't have a static call path you can JIT early and trust to never change. You can't bind a call site to a specific method body, knowing verifiably that it will forever be the same code called from that site. And ultimately, that means you must implement those capabilities yourself, with profiling, self-updating call sites that build up rule and target sets based on gathered information." 

Of course, both approaches have their advantages and disadvantages. The library approach taken by Microsoft has a much shorter time to market and revisions can be shipped independently of the CLR. Sun's approach is already producing good performance (even without the Da Vinci work, JRuby is already posting better benchmark performances than the original C-coded version of Ruby) but does so at the cost of a considerably longer development cycle.

1. Back to top

   Great news

   by Michael Neale

   "The intention is that at least some capabilities of the Da Vinci Machine will form part of the Java SE 7 Virtual Machine specification."
   
   that is really exciting. I hope this all gets taken seriously.

   Reply

• Older >