Rolling Restart to deploy 1.24 the week of 2008/08/18

Fair enough. Good luck on the server release.

Will existing scripts, that are not recompiled to Mono, continue to run on the existing LSL Virtual Machine, or is the LSL-VM being replaced/upgraded in this release also?
If it is the latter, what kind of things should we look for in our existing scripts, such as performance increase etc. ? I ask as several scripts that survived by relying on the sluggishness of the old VM may break unexpectedly if the VM is upgraded and performance increased, so you could get a misleading flood of Server bug reports that are actually LSL Script bugs (such as race conditions) that were previously undetected.

"We have no plans to eliminate the original engine. This will be re-examined after Mono has been live on the Main Grid for a while. But right now it is easier to continue to support the original scripting engine than to migrate all scripts."

From: http://wiki.secondlife.com/wiki/Mono#FAQ

(As linked by the status page Prospero provided in the OP)

caveat: I'm not an expert, nor a software developer, nor a linden, so please take my answer with this in mind.


Here's what probably will happen, from my perspective.

Event 1. Avalability of MONOVM as optional VM choice for new scripts.
Event 2: Default checkmark is moved from LSLVM to MONOVM. (some time later, when stability is proven)
Event 3: Mono-Only LSL commands are developed.
Event 4: LSLVM checkmark is removed. (no longer possible to compile new scripts using LSLVM)
Event 5: Development of other scripting language support, and/or additional LSL elements that wouldn't bave worked on the LSLVM.
Event 6: ???

From what I understand, LSLVM bytecode is different than MONOVM bytecode. This is all pretty alien to me, however the LSLVM, it seems, would be needed "behind the scenes" for many years to come, until such time as either LL could build some kind of LSLVM Emulation mode for the MONOVM... or until somehow the bytecode of every single script on the grid could be decompiled and recompiled through some automated process.

And I can't imagine that would be any small undertaking.

Depricating every single scripted item that was developed before August 2008, wouldn't be a very desirable or popular move. Even 3 years from now, people will still have their fond spots for their legacy devices. Things made by people who are no longer in SL by that time.

So, I think we'll see the LSLVM supported for quite some time.. long after the option to compile new scripts in LSLVM is removed... and even that is probably going to be quite some time from now.

If Mono proves itself I can see the standard LSL engine being restricted to legacy use only by the start of next year. I'm pretty sure any future development of LSL will be restricted to Mono anyways, as it's in everyone's best interests to use the engine because of the bytecode sharing and general speed increases.

I'm not sure about this one. The LSL language itself isn't really changing, it's the stuff underneath that's changing. I could be wrong but I don't see Mono-only LSL stuff in the future.

edit: any update on the paused deploy, Prospero?? Or, if there really aren't any yet, is there a deadline for getting it restarted this weekend vs pushing it out into next week sometime?

Oh it's only a matter of time before some of the things "MONOVM can do" that "LSLVM can't do" will be added to the LSL programming language (maybe something like writing to notecards?).. and those functions won't work if compiled using the old LSLVM.

I see that as inevitable. (heck, it'll probably light up in a different colour in the script editor, and will make the LSLVM checkbox go grey.)

You could be right - that's really not my area - but I can't think of any example of something LSL could do with Mono underneath that it could not do with LSLVM underneath. (aside from things that required the script to have some level of performance/memory)

One thing I hope would be added is some kind of way to pass data between LSL-Mono and other languages, that's a little less hokey than link messages.

Thanks Thordian, but yes I read the WIKI and the Blog, and I am sure that you are as aware as I am that neither is the repository for the latest info

It would appear that LSL code compiled to LSL, rather than MONO, is also being compiled server side not client side on the beta grid, so there is a new Virtual Machine for LSL as well as MONO. In my testing I have noticed several differences in my test scripts, both MONO and LSL over the past week or 2, compared to prior months, so I was hoping that a Linden could give a definite answer to this or perhaps an alternative question, are we going to now have 3 run-time platforms? Legacy LSL, New LSL and MONO LSL?

Update on paused deploy : we re-deployed 1.24 (now 1.24.1) to the pilot group last night, and it appears that the rare crash bug we encountered on Wednesday is now fixed.

We have some more investigation to do before we move forward, so we won't be going forward today. Most likely we will be continuing the roll early next week.

Maybe you will continue to post the updates at status.secondlifegrid.net or blog.secondlife.com either. It's hard to follow whats going on if i have to look at two blogs _and_ a forum (i prefer RSS-Reader to be up-to-date).

While an official reply would be best, I don't see why they'd be be working on upgrading the LSL VM, aside from needed bugfixes and some added features (like Windlight Glow). This is from my experience working on two entirely separate codebases, one of which is the legacy equivalent of the other. There's also the issue of trying to get the Mono VM working as much like the LSL VM as possible at first, which would be complicated by every tweak to the LSL VM codebase.

Thank you for taking your time with this to get the bugs before it hits most of the grid

I couldn't agree more with Damona Rau as we would love to see this posted on the SL gridnet page. I'd rather not have to look at more than one page to find out the status of this "project".

We'll see... there's circumstances where the Mono engine has higher overhead. Also, many updates come "for free" because same compiler is used for both with different code generators: I caught some bugs in the Mono code generation just comparing the two code generators in the viewer source well before Mono was released on the Beta grid.

They're not entirely separate codebases. Most of the ll* calls are the same code, under the covers, a common library called from both VMs. The compiler is the same, with a different backend.

I didn't realize that both VMs could talk to the same ll* libraries. So I guess most of the effort to getting the two to work the "same" has been making sure control structures, operator/conditional evaluation, typecasting, etc are functionally identical? Because, yeah, that sort of thing doesn't really change, I suppose.

For internal routines like "llList2String" they're completely different, of course, but the majority of the ll* calls, and virtually all the enhancements, are just thin wrappers around the physics/asset/etc code in the simulator.

Here's an example of the compatibility changes... one I found when exploring the code:

The CIL code generator evaluated "expression1 operator expression2" as the straightforward "evaluate expression1; evaluate expression2; call operator", but LSL2 had generated "evaluate expression2; evaluate expression1; call operator". This had been taken advantage of in a trick popularized by Strife Onizuka that used code like "list = (list = []) + list + [ new value ];" instead of "list += [ new value ];" because clearing the list in the middle of the expression saved memory, and the code generated was right-to-left so the list wasn't cleared until after it was used. With left-to-right evaluation in CIL, the list would have been cleared before it was used.

That's the kind of thing you wouldn't think of, particularly if you were a C/C++ programmer, because "everyone knows" that the order of evaluation isn't guaranteed. Well, surprise, too late, too much existing code would break, so now the order of evaluation in LSL is guaranteed, and CIL generates something like "evaluate expression2; evaluate expression1; swap; call operator;".

The status blog post has been updated with the expected schedule for the rolling restart next Monday through Wednesday.

Thanks for the explanation and all the hard work, Argent.

So which regions got the update? I would like to visit one.

Try any of the Linden sandboxes, those were included.

@Prospero

Thanks for updating the status page!
I know and believe it's a bit more work for you to update the blog and the forum, but i'm sure many residents will appreciate to the see updates at the blog. It's also good to know, that we have this forum for discussions - this keeps the blog clean.

A question: i've heared that the mono-vm is bytecode compatible to the other vm, why isn't there a way to auto-port the existing scripts?

All what i read is, that the LSL-calls are still the same, even under mono.

with MONO delay of some script (such object rez) will be erased? MONO performance are higher (tested on beta and on the grid) so i have the doubt about delay generated by some functions...

Damona -- I don't think it's that easy, but I will ask the experts inside the lab.

Tayra -- I'm also not an expert here, but I do know that you shouldn't expect the delays to go away any time soon. Some of the performance hits that these functions cause aren't due to the scripting per se, but because they make the sim do other things that are resource intensive. For example, rezzing can be resource intensive-- information may need to be downloaded from the asset server, the sim has to add another object to keep track of, etc. The delays in there are not simply a reflection of scripting performance needs, but of overall sim performance needs.