All in One VM - It's as Good as It Gets

It is possibly one of those times when we are witnessing a plethora of programming languages, each trying to carve out its own niche in the development space with its own set of cool features. The experienced heads tend to think that most of these are really good old ideas from the past which reappear because the technology is now available to commercially exploit them; others become popular because they provide a better approach to solving a particular problem.

Possibly the most blogged about thread raging the community is that of dynamic languages and their support on the JVM/CLR. Suddenly the blokes who used to think of types as the coolest invention since sliced bread, have been voting for dynamic types and ruminate how dynamic languages make programming much easier and ensure better productivity from programmers armed with automated unit testing tools. Robert Martin and Bruce Eckel have expressed this sentiment in switching over from C++/Java to Python, Martin Fowler shares his similar experience with Ruby.

It's 3 AM in the morning and I just finished reading two of the papers on this subject, both heavily discussed in LtU. In Static Typing Where Possible, Dynamic Typing When Needed, Erik Meijer and Peter Drayton of Microsoft, tries to make it a world of both the goods. Fanatics of static typing have been professing the idea of all-safety with well-typed programs. This, they claim is vacuous - static typing, they say is a compile-time abstraction of the runtime behavior of your program, and hence it is necessarily only partially sound and incomplete. This means that programs can still go wrong because of properties that are not tracked by the type-checker, and that there are programs that while they cannot go wrong cannot be type-checked. Dynamic languages, OTOH, may be an automatic choice for modeling truly dynamic behavior through their features like method interception, dynamic loading, mobile code, runtime reflection, etc. In the other paper On the Revival of Dynamic Languages, Nierstrasz et. al. looks at static languages as an obstacle to the effective realization of real applications with essentially dynamic requirements. They suggest languages which can support changes during runtime through features like pluggable types (Gilad Bracha is also one of the main proponents of this), reflection on demand and first class namespaces.

The moot point of the above is that the dynamic languages are back with all their usual artifacts and features and we need to strive for a peaceful integration of them alongside the mainstream statically typed languages. As far as I understand, the only medium of integration is the Virtual Machine (yes, by VM, I mean both the JVM and the CLR) - both Sun and Microsoft should come out with more clairvoyance with their plans to make their VMs a universal medium of support. As Ted Neward yarns

My long-shot hope, rather than prediction, for 2006: Sun comes to realize that the Java platform isn't about the language, but the platform, and begin to give serious credence and hope behind a multi-linguistic JVM ecosystem.

Experts have voted both Sun's JVM and Microsoft's CLR as being unfriendly towards supporting dynamic typing. Quite some time ago, I came across a paper Supporting dynamic languages on the Java virtual machine by Olin Shivers of MIT. The paper points out two areas which need to be improved by JVMs in order to support dynamic languages - more efficient representation of dynamic data and efficient encoding of language specific computational elements. Regarding the first issue, the VM needs to ensure optimization of small scalar data types without doing a dynamic lookup, a feature which has been implemented as value types in the .NET CLR today. The second issue deals with the problem that the JVM is not able to represent all computations which dynamic languages will support - for this he suggests making the JVM a RISC model rather than the current CISC model, thereby enabling the VM to have an extendable instruction set. But doing so, he warns, we may lose out on the safety side - allowing microcode extensions written in C and delivered as raw machine code to be dynamically loaded into the VM requires us to decide why we are going to trust the microcode, and how we are going to verify programs that use these instructions.

The real light of hope in this front comes from the blogs of Gilad Bracha, where he discusses Sun's initiatives to support dynamically typed languages in the JVM. They have been working towards supporting languages like Perl, Python/Jython, Groovy, Ruby etc. through dynamically typed method invocation at the byte code level. Look out for the new bytecode "invokedynamic", at a JSR near you. Regarding how the new bytecode will work, he has the following observation

Basically, it will be a lot like invokevirtual (if you don’t know what that is, either open a JVM spec and find out, or stop reading). The big difference is that the verifier won’t insist that the type of the target of the method invocation (the receiver, in Smalltalk speak) be known to support the method being invoked, or that the types of the arguments be known to match the signature of that method. Instead, these checks will be done dynamically.

Microsoft is also up in arms with lots to offer for supporting dynamically typed languages on the CLR. Features like closures have been implemented using Anonymous Methods and Delegates, Lightweight Code Gen (LCG), along with DynamicMethod class enables easy authoring of languages and late bound calls under the hood of reflection are definite steps forward towards enabling a multi-lingual virtual machine ecosystem.

Hopefully it is not a far cry when I should be able to replace by Strategy with the Blocks of Ruby, while the context enjoys the type-safety of Java. Until then, enjoy programming in Scala, the latest kid on the block which runs on the JVM .. I plan to blog a lot on the cool aspects of Scala, but that's for another day - for the time being, I am losing out on my caffeine !!