Server version 1.24.3 in August of 2008, implemented Mono as an alternate way to compile and run LSL scripts. Mono is a free and open source implementation of Microsoft’s .NET and is sponsored by Novell. This is all pretty old news by now. But there is one feature in the implementation with Second Life that is worth talking about.  Bytecode sharing. 

So, what’s a bytecode?  And how do you share it?

The term ‘bytecode’ came into general usage when Sun Microsystems created Java.  But the concept is actually at least as old as 1966.  It was just called other things such as o-code, p-code and pseudo-code.  The idea behind all of these is that a compiler can translate a high level programming language into a hardware independent set of instructions that can either be translated into machine code or quickly interpreted at run time for a specific hardware platform.  This approach allowed compilers to be created that could be relatively easily ported to different hardware platforms or compiled code to be created that was independent of a specific hardware platform.  The hardware specific translator or interpreter would still have to be created for each hardware platform, but this was a far easier task than rewriting a compiler for each set of hardware to directly produce machine code for that hardware.

And now to the sharing part. The Second Life server will only load one copy of the compiled bytecode for a script, no matter how many times that script occurs in the sim. So, 10 instances of the script use the same amount of memory as one instance of the script, not counting the data. Only the program code portion of the script is shared. Each individual usage of the script gets its own data area. The requirement to support bytecode sharing is that the same script is not recompiled each time it is placed in a new object. For example, each time you want to reuse the same script, either copy the object with the script intact or drag the compiled script from your inventory into each object without recompiling it. If you recompile the script the sim can no longer tell that it is a duplicate copy.

In reality, this may be a small savings in memory. It is likely that in the 1,000s of scripts loaded in a sim, there may be a small percentage of duplication. And those that are duplicated may be small scripts like your fancy window tinting scripts. But, treating scripts carefully to support bytecode sharing is an easy thing to do and every little bit helps.

You may have scripts that differ only in the setting of just a few variables. Having to compile slightly different versions of the same script would prevent bytecode sharing in addition to making it a little harder to maintain changes to the script. In future blog entries, I plan to show several methods to allow scripts to obtain different configuration options so that the same script can be used to perform slightly different operations.