Linden has started
the roll
out of their Mono-powered simulation servers.

Users can now opt into having their LSL scripts executed
using the Mono VM (it remains an opt-in feature, because some
scripts are timing sensitive and the performance increase
could break code).

Some choice quotes from Jim Purbrick's blog post:

As well as providing immediate benefits, the integration of the Mono
virtual machine makes many future improvements possible: the use of
mainstream languages to script Second Life alongside the existing LSL
language; the removal of arbitrary per-script limits on script
resource usage and the use of mainstream libraries and tools for
scripting to name a few.

And:

The integration of Mono is the first step in the evolution of
Second Life into a true software development platform. Thank
you to all the residents who have helped us take this first
step.

Congrats to Linden on their launch!

The Technology

From a SecondLife developer perspective, some of the
technical details about how Mono is integrated into the Second
Life simulators can be
found on their
Wiki.

When a user opts into using Mono, a special LSL compiler
that generates ECMA CLI byte codes is used. The resulting
CLI byte codes are then instrumented with some magic (more
below) and then the code is exectuted using the Mono VM which
translated the bytecodes into native x86 code.

I find the SecondLife technology fascinating. Embedding
Mono into SecondLife was not an ordinary task, it was not just
a matter of linking with Mono and writing an LSL to CIL
compiler.

SecondLife distributes the virtual world on hundreds of
servers, and as visitors move through the virtual world, their
inventory, character and scripts migrates from server to
server.

This migration requires that running scripts be suspended,
serialized to a database and their execution resumed on a
different server. This means that all the state of a script,
including the current location must be preserved while the
user navigates across servers.