OOPSLA '09: Dynamic Languages Symposium (DLS)

There were three interesting talks that I attended at the DLS this year:

Of Scripts and Programs: Tall Tales, Urban Legends, and Future Prospects

Jan presented the investigation that he and his team did to measure how much dynamism programmers used in Javascript – the most ubiquitous scripting/programming language on the web today. He had a good sample size, much bigger than most experiments that I have seen. And definitely not like the paltry, non-representative data that most other research papers have in their evaluation sections. His team surveyed major web applications that utilized Javascript heavily including 280slides, GMail, Facebook, Flickr and Apple Me.

Some aspects of their evaluation include:

• Size of code (in megabytes)
• Prototype chain lengths – Almost like inheritance chains in Object-oriented languages
• Variadity – Javascript allows you to call functions of n arguments with m arguments. So how apps out there use this feature?
• eval(...) – which can used sanely to grab data from JSON or used dangerously to evaluate any string as code.

The conclusion? Some of those apps really use almost every dynamism that Javascript has to provide!

His solution? Yet another programming language (but, of course :-)). His language is called Thorn. I don't have the time to look at it yet, but it reminds me a lot of Strongtalk language with optional typing.

Jan's slides should be available from the DLS website soon.

I also had the chance to ask someone from Google about how they use Javascript. And he basically said that they used a more disciplined approach to it – certain features just aren't used or they are used very judiciously. Some people really like the dynamism of Javascript and others just use it almost like another Java.

Optimization of Dynamic Languages Using Hierarchical Layering of Virtual Machines

Here's a crazy idea: what if you wanted to run Lua on the Lua VM on the ActionScript VM?! Now, why would anyone do this? To test out their optimization technique for layering VMs, of course.

It's a rather circuitous way to evaluate this but it seems to be the easiest route. After all, you don't want to write a VM just to be able to try this out. You just want to use an existing one. And the Alchemy project provides an easy way to translate the original C-based Lua VM to ActionScript.

Of course, the caveat of such an evaluation is that the implementation will be so slow in the first place (the presenter was honest and mentioned this early) that it is relatively easy to get speedups no matter how trivial or naive your technique is.

Hosting an Object Heap on Manycore Hardware: An Exploration

This is a continuation of Dave Ungar's work which he presented at the Squeak BOF at OOPSLA 2008.

In a nutshell, he implemented a simple benchmark (baton passing) between different Squeak Smalltalk VMs running on the 56 (it has 64 cores but some of them are reserved) cores of the Tilera multicore processor.

His goal with this experiment was to investigate what kinds of problems we would run if we are going to use manycore (not just multicore) processors. With manycore processors, you have non-uniform memory access and it becomes infeasible to maintain true cache coherence between those cores. In other words, you do need to be aware of the location of your data (much like what the distributed computing folks have been doing).

This is in contrast to what Intel's multicore chips are doing. Even in Larrabee with 10+ cores, all the cores still maintain cache coherence.

I liked the talk because it presented a different view from all the other research papers that I have been reading where they try to solve the problem (or push the solution as far as it can go) for multicore systems and just implicitly assume that it will scale to manycore. People are trying to hold on to the shared memory model for as long as they can and trying very hard to not use a message passing system.