Mono and SL's future- a nuts and bolts discussion by Babbage

SuezanneC Baskerville posted about this in the Resident Answers forum, however I think it's more of interest to scripters. As well I've found how to get to the video *without* installing Microsoft Silverlight.

http://www.langnetsymposium.com/2009/talks.aspx

Scroll down to #17 Jim Purbrick and click on the WMV link to download the video.

VERY informative.

Thank you so much. I already installed Silverlight for this but now I can undo that.

um...um..um... i think ive now heard all the um's i want to hear!

Eek! They serialize the stack on every context switch. Eek!

Managed pointers on the stack can't be serialized, so they have to wind back execution until the managed pointer is gone.

They limit scripts to 64k, but you can have lists and strings that are 64k each between yeild points, so you can have many many times 64k temporary storage. But only one script at a time, so that's OK.

There's a lot of nasty things you can do to screw up the scheduler, and people are doing them.

He's talking about stopping adding new features to LSL. I think that's way premature: there's a lot of scripts that work better in LSL, less serialization, better context switching, better sim crossing. Also, while Mono scripts average 9k. LSL2 stcripts are all 16k... if your script is pushing the memory limits in LSL2, but you can keep it in LSL2, you'll use 1/4 to 1/3 the memory. And script memory is the current server bottleneck.

He's talking about running untrusted code, but it's misleading. They're doing the compilation on the server, they're not taking arbitrary assemblies and running them, they're using a safe compiler (LSL compiler) as the sandbox, they're not using a VM sandbox.

I have a question about this, maybe you'll know or someone else, or it's a yet to be determined. LSL2 scripts take 16k memory right off the bat, no growth no shrinking, 15k memory is allocated per script, where as Mono is more dynamic. My question is, with the new memory pool system, are they going to keep this system, with LSL2 scripts still getting the 16k chunk, or are they going to make it like Mono, where memory given is what is requested?

I don't know if they will allow you to specify less than 16k for an LSL2 script. It would be a good idea if they did, since most of them are nowhere near 8k.

Back when Mono first came out, this was asked to Peripaise Linden, and he stated the dynamic memory allocation was also being used for LSL2. So it's already happening, LSL2 scripts only allocate what they use.

That's not what Babbage implied in that talk... he said that an LSL2 script is serialized by writing 16k of memory to disk.

Just to clarify the terminology, LSL2 is the language, (LSL1 was a language in its own right, just a very bad one). LSO is the asset type used by the old VM and the VM's de facto name. For the sake of keeping the two implementations of LSL2 seperate, lets refer to them as LSL-Mono and LSL-LSO... or just drop the LSL prefix altogether. But refering to the old VM as LSL2 is confusing (especially if you want to talk about improving the language by creating a new iteration of it... LSL3).

LSO is serialized by writing the 16k block of memory to disk. No further conversion is needed. That said, it does have dynamic allocation with-in the 16k block of memory that is statically allocated... but that is nitpicking.

so effectively no, LSO scripts aren't dynamically allocated?

ETA: and now I know why script state isn't saved on region crossings for not running scripts in objects... only active scripts are passed to the new sim, whereas the entire serialized section is written with an object save.

That sounds like a bug but does sound like what could be going on.

The thing with LSO is that it was not designed with OO principals in mind. It was designed by a C programmer. You can think of the entire script as a huge structure (which happens to contains pointers to other areas within the structure). But the point is, it's not a class, its a binary block, it's just a block of memory for which the interpreter adds meaning by wrapping the block in a class. To serialize all it has to do is wait for the current OP code to finish running, update the structure (which it does automatically with each OP code instruction) and just save the structure by copying it. All serializing is doing is stripping the wrapper when it is safe... Something only a C programmer would dream up.

LSO though doesn't even use the structure type for the memory block, instead it uses hardcoded addresses to access the members at static locations.

LSO in the end is a binary format for which there is no line between data and information; there has been little effort to hide the underlining binary structure. Consequently... serializations is really fast.

Or an assembly programmer, or a Forth programmer. For a real-time environment that's not a bad thing. If they hadn't, they never would have been able to get scripting working in SL at all.

Agreed.



This sounds somewhat contrary to what Periapse had said. He stated that LSL-LSO was only allocating the memory the script needed while running on the server, the same optimization being enjoyed by LSL-Mono. I asked this on several occasions and he never wavered on this point. But I suppose that doesn't mean he wasn't wrong.

But seeing how they have an active plan to phase out LSL-LSO, it's all moot.

so if I said I pulled a similar trick in VB6 to get past certain data object manipulations that weren't allowed for private classed objects would that be funny... or sad?

You got me, all right, all right. I meant it to mean that it wouldn't have dawned on anyone who was an OO programmer. There are plenty of non-OO languages other than C that this approach would have been natural to.

And you are correct, LSL would have really really sucked if they hadn't done it the way they did. I never said that the non-OO approach was bad, I would have done it much the same way actually. I don't much like the way OO turns it's back on how information is data, how everything is data. People forget that everything is data and you get buffer overflow exploits.

@Void: To answer your question: Clever. Take that to mean what you like. I might have done the same... I wasn't brought up on OO.

Of course, real programmers consider newfangled languages like "C" and Forth wimpy and effete: http://www.pbm.com/~lindahl/mel.html.

The first computer I worked on had 13-bit words and used decimal arithmetic, but I was never a "real programmer" like Mel.

Yp real programers started their machine code on the first datasette file load before loading the main program so it could all fit in 3.5k

Real programmers copy their inner loops to low memory so they'll run out of the registers.

Real Programmers:

http://xkcd.com/378/

Real programmers use punch cards and paper tape, not this newfangled magnetic storage. It won't last, you know, there's no future in it.

Real programmers wonder why bubble memory didn't catch on.