Cory and Jim talked about Second Life, the current scripting system used in Second Life and their efforts to embed the Mono VM inside Second Life. The first part of the presentation was done by Cory and he presented an overview of Second Life and the audience was hooked on the virtual world that they have created. They had to stop answering social questions about Second Life so we could move into the actual technical details.
Jim, who is a blast, introduced the technical challenges that Second Life has on scripts. They need to be able to load and unload thousands of scripts in a continuously running process, and they also need to stop scripts at any point to either suspend them or to move to another computer.
Second Life maps computers to areas of land, so a computer is in charge of running all the simulations, physics and scripts for a given portion of virtual land. When a person crosses the boundaries the scripts have to migrate from one machine to the next machine.
Today the scripts running on Second Life are a bit slow, so they are looking at Mono and the CLI as a way of providing more speed to their users and hopefully allow developers to write in other languages other than their Linden Labs Scripting Language.
They have a compiler that translates their scripting language into CIL bytecodes, and the preliminary results give a performance increase between 50x and 150x faster execution with Mono.
The challenge is to stop and save a running script. This is something that is relatively easy done with their scripting language, but it becomes trickier with the CLI.
Their implementation instruments the generated CIL assembly to allow any script to suspend itself and resume execution on demand. This is a bit like continuations, the main difference is that the script does not control when it is suspended, the runtime does. The instrumentation basically checks on every back-branch and on every call site whether the script should stop (in Jim's words, "eventually, you run out of method, or you run out of stack") and if it must stop, it jumps to the end of the method where a little stub has been injected that saves the state in a helper class and returns.
A very clever idea. Hopefully the slides for the presentation will be posted soon.
Following my attorney's advise I have obtained a Second Life account.
Ruby in .NET
There were two presentations on Ruby running on .NET, the native compiler that John Gough's research team is working on and John Lam's RubyCLR bridge.
Compiling Ruby is challenging for a number of reasons, the lack of a language specification means that sometimes the only specification for the behavior is the source code and because Ruby has a lot of features that do not map easily into the single-hierarchy, multiple-interface object model that is part of .NET. So Ruby.NET has to generate a number of helper classes and runtime support to provide the expected behavior.
John's approach is different. Instead of creating a compiler for Ruby, he wants to reuse the existing Ruby and provide a good bridge to expose Ruby objects to the CLR and CLR objects to Ruby. He had some good demos of it, and he showed an interesting interactive shell that he built with Ruby and Avalon.
During Gilad Bracha's presentation he pointed out that some languages fit naturally into the .NET and Java VM models, and those languages tend to feel like syntactic sugar for the existing VM.
A few compilers for dynamic languages like IronPython and Ruby.NET as well as C++ require features that can not map directly into the .NET and Java models so it is necessary to create an independent universe and merely using the Common Type System (CTS) and the Common Language Specification (CLS) as "interoperability points".
The conference really was split in two groups: those attending the talks (back-to-back with a couple of breaks) and those in the "kitchen track".
In the kitchen track there were plenty of interesting discussions, among them, should there be a "CLR-2" or a "CLS-2" that provides the shared runtime support for dynamic languages and standardizes the second layer to allow higher interoperability of these new layers created for scripting languages.
Don Syme designed the generics support for the CLI and C# and did a fantastic presentation.
He has since moved on from Generics and has been working on F#. His presentation and demostrations were fantastic. I would probably have benefited more from this talk had I known more about functional programming.