Thanks For The Memory
Sunday, January 21st, 2007 at 5:09 AM by: babbagelindenAs Cory announced at SLCC last year, work on embedding Mono in to Second Life as a next generation scripting engine has been on the back burner while we concentrate on stability, scalability and capabilities. However, the work on Mono took a significant step forward last week.
Back in August when we gave the Lang.Net demo I noticed that the simulator memory usage was steadily growing over time while running Mono scripts.
My initial suspicion was that managed objects weren’t being collected properly, either because I was holding on to handles erroneously or Mono wasn’t garbage collecting aggressively enough, but Heap Buddy soon showed that this wasn’t the case. With 40 scripts running in a simulator, the Mono managed heap was only 1.8MB and only ever reaching 80% capacity, encouraging results as they showed that there was no great memory overhead imposed by the runtime.
With the managed heap looking like it was working properly I started looking at the unmanaged C++ heap with Valgrind, but the results from memcheck didn’t seem to reveal the problem. A few memory leaks in the Mono runtime were identified and quickly fixed by Zoltan Varga, but none of these were large enough to account for the simulator bloat we were seeing and most were one off leaks occurring at runtime initialisation.
Next up was Valgrind’s massif tool, which analyses the unmanaged C++ heap over time. Massif quickly showed steady growth in the memory consumed by Mono’s mempool. The mempool is cleaned up when the Mono runtime is shut down, so the memory wasn’t being shown as a leak by memcheck, but with the mempool growing continuously over time it would soon degrade simulator performance and eventually lead to crashes.
The great news is that a week ago Paolo Molaro was able to use the memory allocation stack trace information collected by Massif to fix the problem which was caused by method info caching. I spent some time last week re-running my tests and it seems that Mono is no longer growing in size. Thanks Paolo!
With this development, the work on Mono takes another step forwards. We’re currently working on moving script compilation to our new web services platform and once that’s done I can wire in the LSL to Mono compiler, bytecode injector and verifier as web services and then the main pieces of the work on Mono will be done.
Many thanks to Miguel, lupus, Zoltan and the rest of the Mono team for all their help.
January 21st, 2007 at 5:19 AM
does this mean that we’ll soon have a nice OO language for our scripts? =)))
January 21st, 2007 at 5:26 AM
awesome, maybe we can work on the physics engine when mono is done?
January 21st, 2007 at 5:29 AM
Fantastic! So how is the serialization going that allows av’s and scripted objects to travel between sims?
January 21st, 2007 at 5:30 AM
I just computer savvy enough to followed your explanations, but I’m not enough to draw conclusions about where exactly this gain will be realized. Could someone please provide a short briefing on what this advance means, for either Linden for residents? It would be much appreciated!
January 21st, 2007 at 5:52 AM
Regan, in the short term, it means faster scripts.
In the medium term, (I hope) it means more powerful tools in scripts by opening selected parts of the Mono standard libraries.
In the long term, we’ll probably be able to upload our own Mono assemblies: that means using more powerful languages than LSL, which is quite limited compared to C# and other modern programming languages.
January 21st, 2007 at 6:06 AM
waw , i love faster scripts
January 21st, 2007 at 6:06 AM
.NET and handling/marshaling a lot of unmanaged code is a great recipe for memory bloat and headaches
I’m glad you figured out the problems.
January 21st, 2007 at 6:24 AM
ALRIGHT!!!!!!!!!!!!!!!!!! WOOHOOOOO less lag better running objects!!!!!!!!!!!!!!!!!!!!!!!!!!Been dreaming for this for a long time!
January 21st, 2007 at 6:25 AM
This alone will make sims run better and faster….Im in heaven!!!!! THANK YOU LLABS!!!!!!!!!
January 21st, 2007 at 6:27 AM
“3 point 5 gigawatts!!!!! Marty, maybe plutonium is available at every corner pharmacy in the time you come from, but in 2007 it’s a little hard to come by!”
Man, I’m a burnt out developer. Good news on progress, bad news on having to learn yet another thing
January 21st, 2007 at 6:30 AM
It means fewer sim resources spent on active scripts, which translates to experiencing less sim-side lag.
Babbage: What are LL’s current thoughts on opening up some of the other potential benefits of implementing Mono? Are there specific libraries/tools that will/won’t be opened up? Is the ability to upload our own assemblies being considered?
January 21st, 2007 at 6:31 AM
YES YES storm……….been dreaming of this day for over 1 1/2 years
January 21st, 2007 at 6:32 AM
Ever since I first read about the impending upgrade to using Mono, I have been eagerly awaiting news, and this is simply incredible news indeed! I just hope the next steps wont take nearly as long, because if there’s one thing SL truly needs, it’s much faster scripts. The current LSL was a good start, but with the increase in people on SL, and hence the amount of scripts needed, as well as the increased number of execution of each script, I think this is a sorely needed step, and I applaud you for working on it, and obviously wanting to get it up and running as much as (I think) every single LSL scripter. ^^
January 21st, 2007 at 6:43 AM
Double you zero zero tee
January 21st, 2007 at 6:47 AM
I’m not entirely clear on what mono is. Is it a new language? Will I have to learn different formatting and capitalisation rules? Will I still be able to use the llxxx commands?
Aside from more memory, I have no idea what mono is. or what(if anything) mono stands for. Can someone fill me in?
WarKirby - Novice scripter
January 21st, 2007 at 6:49 AM
How will this effect current scripts? Those of us who only know LSL will we still be able to script as we can now?
January 21st, 2007 at 6:55 AM
scripts now with Be LIGHTER FASTER, and more mangeable then with LSL. Less Lag is the result because of less bulky scripts that are over sized. MONO will produce faster lighter less (Energy sort of speaking) will a sim is running scripts.Smoothy and less stress in a sim. All In ALL this means More population in a sim or Island.. BABY WE ARE MOVING UP!!!!!!
January 21st, 2007 at 6:55 AM
without LSL bulkyness.sorry a typo
January 21st, 2007 at 6:59 AM
I thought I had mono once. Turned out I was just really bored.
January 21st, 2007 at 7:04 AM
Kitten Lulu, Thanks for the reply!
Hmmm. I would love to be able to script in C# instead of learning LSL. Oh, well, I’ll need my own scripts sooner rather than later, so I suspect I can’t avoid the LSL learning curve. But girl can dream….
January 21st, 2007 at 7:09 AM
I have a crush on Babbage
*sighs and flutters eyelashes at gale force winds*
January 21st, 2007 at 7:23 AM
Mr Linden Dudeness, i admire you and all but what the heck does all that translate to people like me who have no idea what you’re talking about buddy. What does it mean in English?
Don’t mean to be rude, i just don’t know anything about scripting, i’m just a regular joe.
January 21st, 2007 at 7:33 AM
Shouldn’t be a surprise that there were leaks. I’m still half-interested in a sort-of sort of way about how the system deals with race conditions, I ran into such a situation when writing a RSS reader for Drupal (umm - llHttpRequest still is gimped btw).
I certainly would like more options than Mono. I know its cool and everything, but de Icaza is an interesting person for some, but… there are many other languages which can be used with very similar - if not the same - hooks.
What I would like to see is more of the exposure of those hooks (a la libsl) so that there are options. Sure, C# is a good language, but its not the best language for everything… and there’s a whole lot of everything in the future… I think you know what I mean, but I haven’t read it anywhere, so behold the dead horse beaten again.
Its nice to move LSL to a language that is less proprietary, but in doing so I would hope plans are made for other options.
January 21st, 2007 at 7:35 AM
Usagi - Yes, Mono may mean less lag than LSL, but is it really the best choice? Just saying…
January 21st, 2007 at 8:03 AM
Is it just me, or is there a widespread misunderstanding that Mono is a language choice as opposed to a framework choice? Might have been a bad idea to link this blog entry from the logon page
January 21st, 2007 at 8:23 AM
Nobody, well lighter faster and less bulky means less sim stress ……So I say Yes……….What you pick ?
People have been asking for MONO scripting language for a very long time. So I say not so for a misunderstanding……..
January 21st, 2007 at 8:23 AM
Quick google search:
http://www.mono-project.com/Main_Page
January 21st, 2007 at 8:31 AM
gad this was like listening to specialists talking in the back room … “the hyperglocemulator is fixed now that the red cell count is down…” prospects for the patient sound good now yay!
January 21st, 2007 at 8:31 AM
If it means less lag, I’m all for it–I’m SO sick of going to church and not being able to MOVE around because we have the limit of 40 people or so! It REALLY distracts from the services and then I can’t focus on WHY I’m even IN church.
Less Lag=Happy Churching!
and dancing!
and shopping!
and building!
and…well, you get the picture!
January 21st, 2007 at 8:36 AM
Excelent! I remember Cory saying that sometime within the next two quarters of the year we’d be testing/implementing MONO and it looks like its gonna be on track. Just curious though, will MONO testing reside only on the Beta grid or will special sims be placed on the main grid for the testing? If its the latter may island owners volunteer their sims for real world variable testing?
January 21st, 2007 at 8:42 AM
Just curious; what will the Mono language mean for script functionality? Will performance be increased? Will we be able to do things not previously possible with LSL? In short; besided different syntax, what other benefits will Mono bring to SL scripting?
January 21st, 2007 at 8:51 AM
Woot, yay for geeky blog posts! Thanks for giving us insight to how the internals of the system work; I know I for one really appreciate that.
January 21st, 2007 at 9:02 AM
Mono is a platform, not a language, so there’s no such thing as a “Mono scripting language.”
A number of languages, including C#, Java, and Python can be “compiled” to run on Mono.
Similarly one would be able to compile LSL to Mono, and I’m guessing at the initial swichover to Mono, LSL would still be the only scripting language directly supported by the client.
From the blogs, it seems that Mono is much faster than the current LSL virtual machine. Hopefully the conversion to Mono also means the relaxing of things like the 16kb script memory limit (cross-fingers.)
Will it mean less lag? I doubt it, really, because scripters are a greedy bunch, and tend to use up any and all available resources given to them.
But it could mean a new class of more advanced scripts, implementing things which would be too slow or too constrained under the current system. Smarter attachments, better vendor systems, etc.
As for whether or not Mono is the right choice… the only other choice I see would be the recently open-sourced Java (the platform, not the language.)
While Mono will always lag behind .NET, the open-sourced Java is “the real thing” fully supported by Sun and already proven in numerous mission-critical environments. Hence problems like these “memory-leaks” would have been noticed and solved awhile ago.
-peekay
January 21st, 2007 at 9:02 AM
It would ne nice if they could fix the current presumed memoey leak which crahses the Mac version once every hour or so, and get it to stop writing the half a gig or so a day of temp files it never cleans up.
And you guys miss the poiny. It won’t be less lag, because as you’ve already jumped up and down, going cool, I’ll be able to do so an so, scripts will just get bigger and more ‘cool’ and expand to fit the space…..
January 21st, 2007 at 9:06 AM
to pick up on Nobody Fugazi’s point … moving in the direction of non-proprietary seems like a Good Thing.
hence acclaim for Mono, and the release of the OSS version of the client ported to Linux (i refused to install M$ Windoze just to play games), with the 2 going hand in hand, so pretty soon i suppose the client packages will be hosted at sourceforge.
but really, girls and boys, Python is the hot language right now.
January 21st, 2007 at 9:06 AM
droooooooolzzz:)) kewl!!!!!!!
January 21st, 2007 at 9:13 AM
Will get use to it there are three sets of users on sl. MAC,WINDOWS, LINUX….All are needed to made a better well round System for Sl.
Mono is what we been ( or most Us that understands The importance of MONO is ). This indeed is a bright spot in these dark days of Free account abuse and griefters around SL…..
January 21st, 2007 at 9:14 AM
Tell me again please how this all is going to help protect the future of SL from attacks by Micrcosoft? And once SL gains significant traction, hostile attacks from MS are absolutly certain. And mono gives them the weapon to attack with, as they have already done with Novell.
January 21st, 2007 at 9:15 AM
Oh boy here comes all the know-alls………:/
January 21st, 2007 at 9:25 AM
att his point I’m a skeptic about any change not directly aimed at bug repair.
I feel like I’m talking to a child finding excuses to bring desert.
Finish your vegetables, then you can have cake. We all want it junior, but at this point it’s a matter of principle. My patience is running thin.
I’d make a comment about what poor eating habits now will do to you later in life, but I don’t want this to get personal. Suffice to say that LL needs to go on a diet.
When SL starts WORKING PROPERLY instead of progressively GETTING WORSE I’ll be more welcome to CHANGE.
I simply don’t see any change as a good thing. Fix bugs you already have before making new ones. THink I’m being mean? Look at your track record.
January 21st, 2007 at 9:29 AM
Good stuff, Babbage!
Two questions: one is how does the schedule for getting this in-world look? Highly-disclaimed-wild-guesses are fine..
The other is how will this impact existing scripts that, for whatever reason, can’t be recompiled? Will there be any way for them to get the benefits of MONO?
Thanks!
January 21st, 2007 at 9:35 AM
@Kitten - Perhaps you should read the Mono Project page linked above…
I calim no knowledge of Mono, but just reading what’s there, I see the following (re: Python is teh new hotness)…
http://www.mono-project.com/Languages
cliff’s notes: Mono is a platform with compilers available for a whole boatload of languages, including Python (…and C#, Java, Boo, Nemerle, VB.NET, JavaScript, Oberon, PHP, Object Pascal, and a few others).
January 21st, 2007 at 10:03 AM
Eh, I don’t particularly like server-side compilation (I can’t fitz with the bytecode!), but I suppose it saves everyone from having to install the .NET framework/hook into mono on Mac/Linux
January 21st, 2007 at 10:33 AM
Hey and how about a real debugger while we’re at it? grin.
January 21st, 2007 at 10:42 AM
This is a great step forward, glad to hear about the success after all this hard work debugging. Keep it up!
I hate to sound negative but after this release my friends and I are seeing lots more problems crashing our client software. Object edting is now tricky due to new bugs with the selection tools, gesture editing is still broken, textures may still have problems. Certainly there has been huge efforts on the scalability and capabilities which are very much appreciated. I’m simply hoping the stability fixes mentioned in the first line “while we concentrate on stability” get some more attention again.
January 21st, 2007 at 10:45 AM
If you haven’t seen the Cory and Babbage presentation showing mono, it’s worth viewing. The first half is kind of “SL Tech 101″ by Cory, then Babbage/Jim takes over about half way through. The final 10 or so minutes actually show SL on a test grid running mono - it runs scripts about 100 - 150 times faster in this demo! See it here:
http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/Jim-Cory-SecondLife.wmv
Nobody: I’m convinced mono is absolutely the right choice. It doesn’t just limit you to C#; it also does Python, Java, Boo, JavaScript, PHP, Object Pascal and more…check it out here:
http://www.mono-project.com/Languages
I hope this info helps.
Regards,
-Flip
January 21st, 2007 at 10:52 AM
Now that I have checked out mono, as a scripter, I am almost wackin.
I am assuming LSL - CLI conversions (automatic and invisible?) are the rule… But you should consider letting us upload compiled CLI from other sources (php, etc). Php style array handling? (ooo, talk dirty) VB basic controls on dialogs? (oops, where is that kleenex?) Its looking like there are things happening here. I like it.
And for the bitch-n-whine crowd… This WILL fix bugs because what we have now is like having cheap tires on a Porche. Get the scripting engine up to spec and the whole machine runs smoother. (yes Physics should be next)
January 21st, 2007 at 11:18 AM
Your going to need it and more with the 11 million residents being on-line this year. =)`
January 21st, 2007 at 11:22 AM
Alexander Regent Says: “3 point 5 gigawatts!!!!!”
Sorry.. I just COULDN’t let this slide!
one point twenty one
(sides.. I really can’t say anything about this whole mono thing.)
I do have a question though. Right now, LSL is as manageable as, let’s say.. Javascript. we’ve got a dictionary of terms, we assemble the scripts. Some of our scripts do really bone-headed things. (when paid, send to linkset “paid”) that kinda stuff.
I’m a builder.. I’m really good with legos. Prims are a lot like legos, but so is LSL.. if I can figure out how to put the parts together in the right order, I can make something work.. and if I use more, smaller specialized pieces, I can even make it understandable to me (I can translate a quatermelon into actual xyz degrees.)
But I’m like really scared when we start talking about “programming architechtures” and words like “c++” start floating around.
When this all boils down.. will there still be an “LSL2.0?” or something? a dumbed down set of legos that people don’t need to take graduate programming courses at MIT in order to make a waving flag or a sign that lights up when you enter the room?
because I really don’t want to have to become a “programmer” just to turn on the lights.
January 21st, 2007 at 11:30 AM
Hey Web Page, do you have any idea what the rest of us are talking about here?
January 21st, 2007 at 11:34 AM
It’s on the server side, Winter. Residents will still only be able to use LSL..
January 21st, 2007 at 11:35 AM
I’d put up with LSL being frozen for the next 6 months, if it meant I could use C#, JavaScript, PHP, Perl, or Python that much sooner!
Ok, well if you want to bump LSL memory size up to 32k, and http request buffer size up to 8192, I wont complain
January 21st, 2007 at 11:36 AM
I second Bucky’s request about memory size and http buffers. That is something that could help a lot right now.
January 21st, 2007 at 11:43 AM
Well at least they didnt decide to use Cobol
January 21st, 2007 at 11:44 AM
Bucky, it’s not going to mean that. Not in the short run at least.
This is only a new back end for LSL. A back end that is much much faster though.
January 21st, 2007 at 11:53 AM
To those who say that LL should focus on fixing bugs, I think that a lot of the problems we’re seeing come directly and indirectly from core architectural issues that will be significantly alleviated by improvements like this. In the long run, and probably the short run as well, LL can’t affort to be in the compiler and VM optimization business. I certainly hope that Mono proves to be the best path going forward, I’d have to guess that LL is going to be one of the first major commercial customers of that project, unless you follow the argument that Mono is really just .NET which means that they’re able to ride on the coattails of Microsoft’s R&D. I, too, would have liked to seen LSL compiling to Java bytecode rather than Mono/CLI, but at the time this project started, Java’s open source position was unfortunately as clear.
January 21st, 2007 at 12:29 PM
that link to http://www.mono-project.com is dead. anybody got a good link?
January 21st, 2007 at 12:31 PM
That link works for me… maybe just a temporary glitch.
January 21st, 2007 at 12:32 PM
I can see why they need known sizes for the runtime environments but I’d think they’d be able to implement several standard sizes. I mean how many scripters have scripts that just contain a link message event and a handler for texture changes or something similarly tiny. As it is right now all scripts in LSL take 16kb regardless of how much they ever actually use. How about something like a size selector for the run time, say start at 2 maybe 4k and double in size every increase up to a max of 64k, so our small scripts can use less memory and our large scripts can also use less memory (because it’s much more efficient to have one 64kb script than 5 scripts to emulate 64kb of storage due to copies of code in each script plus additional overhead of verifying which script holds what)
January 21st, 2007 at 12:43 PM
@Winter:
They have confirmed in the video above that LSL won’t be going away. To use an analogy, it’s like taking a 4 cylinder engine out of a car and fitting it with a Viper’s (10 cylinders). Same old car, but it goes so much faster it’ll cause problems for some (like those lazy scripters who rely on LSL being slow to time certain things). It’s also analogous to requiring a gas/oil mixture for your old engine, and then any kind of power source (gas, ethanol, battery, or hydrogen) for your new one.
The LSL scripting engine we have now was purpose built to run only LSL code. But as smart as the Lindens can be, they don’t have the experience required to write a REALLY good scripting engine, and so it’s a bit on the slow side. It works, that’s all we can ask for, but we could do better. Enter Mono, which was built to use another kind of language which is more efficient (bytecode), and has compilers which allow a variety of other languages to be converted into this version. The people who work on Mono also focused their attention on learning to design this kind of thing; they live, eat, breathe, and sometimes dream about scripting engines. So aside from a few technical problems, all that needs to be done is for an LSL to bytecode compiler to written and presently written scripts should work just as they always have. Ideally, nothing should change about LSL, and we won’t need to learn anything else.
Ideal situations don’t always come up though, so we’ll have to see if there isn’t just a little bit of a hitch in the conversion process.
January 21st, 2007 at 12:46 PM
Moving to a common interpreter will definitely make things better. Why? Because it’s got so many more uses, developers, testers, and so forth. It’s a more mature product. Also, the current LSL is actually LSL v2; I forget the details, but there was an earlier version that Cory Linden occasionally has mentioned.
Most of the problems I’ve seen in sims with time dilation and sim fps have been created by current scripts gone berserk. Having a stable, mature virtual machine to execute script instructions should also remove a lot of the problems we’re seeing with sim performance.
January 21st, 2007 at 1:22 PM
“…while we concentrate on stability, scalability and capabilities.”
Capabilities are perhaps there…. seriously though, where’s the scalability? And most importantly show me a single week where there was anything close to stability. You guys really need to concentrate on a functional product before you go and plug more into it.
January 21st, 2007 at 1:32 PM
@Samuel Geiger
Um… this IS a huge part of making a more functional and scalable product. Implementation of Mono will reduce overhead drastically on sim servers, resulting in more stability.
Aside from this, the grid is at a breaking point where a few lines of code to bandaid bugs is no longer sufficiently helping the problem. This is among the many needed major upgrades.
January 21st, 2007 at 1:37 PM
Wonderful news! One step closer to the day I can script SL objects in Python.
Oh, and it has to be said: “Zoltan Varga” is the coolest name *ever*.
January 21st, 2007 at 1:38 PM
@Samuel: SL population has exploded exponentially, doubling in population every few of months. We only crossed 1 million residents recently, then suddenly hit 2 million, and now approaching 3 million.
The fact that SL still works fairly well is testament to what Babbage and team are doing.
-peekay
January 21st, 2007 at 1:38 PM
w00t!
January 21st, 2007 at 1:39 PM
Alexander Regent Says:
January 21st, 2007 at 6:27 AM PST
“3 point 5 gigawatts!!!!!…..”
It’s supposed to be:
“1.21 jigawatts?!”
[/Movie geek]
January 21st, 2007 at 1:40 PM
@FlipperPA: just watched the video, very neat. I loved Babbage’s demo on a Mac running xcode…. at Microsoft event.
-peekay
January 21st, 2007 at 1:45 PM
Will it fix the crash lockups while scripting like I had 4 times last night before I gave up??
January 21st, 2007 at 1:56 PM
Yay! Alexis, no.
Glad to hear that something actually went in the positive direction of mono. I can’t wait until I compile my first script with it!
January 21st, 2007 at 2:29 PM
Ok i wanted to add this, there is 150 million on myspace if im seeing it right, if just a quater come over to sl it will make it interesting. What does this have to do with scripting u ask i have no idea =)`
January 21st, 2007 at 2:58 PM
Fascinating!
Now if I would be able to login to any region that would be nice!
January 21st, 2007 at 3:01 PM
If I undertsand this right loggin into Second Life is asof now contingented.
Thanks for the smoke!
January 21st, 2007 at 3:31 PM
I watched the talk at Lang.NET, really interesting stuff. Microthreading and continuations are real cool things.
January 21st, 2007 at 3:40 PM
@starcomber Vig
You’re absolutely correct. The Lindens have dozens of positive announcements just sitting around to avert attention away from grid problems! Why didn’t we all see it sooner!?
January 21st, 2007 at 4:10 PM
Could a friendly Linden clarify whether this migration will result in additional user-side scripting options? My understanding from the posting is that:
(a) first the sim code will benefit from a new LSL implementation under Mono,
(b) later on, maybe residents will have more scripting language choices too.
January 21st, 2007 at 4:12 PM
I don’t bash LL’s works lightly, neither I criticize LL without good reasons.
SL is an incredible patchwork and is inevitably messy, from server to client not to mention the horrible non-standard and unusable UI we deal with every day.
I don’t see any future, Mono or not, unless the platform gets scalability score.
So far it fails on all fronts, retention numbers are silly, reliability is no priority on LL’s side.
Getting old in SL cuts the nice verbiage and shows what the real path is.
User’s pool is an illusion.
Obsolescence is where this platform is going.
January 21st, 2007 at 4:54 PM
Does that mean I have to learn a complete programming language now?
January 21st, 2007 at 5:48 PM
As far as I can divine from all this, the summary seems to be:
1. Mono is a bytecode-consumer. It’s a back-end, not a language.
2. We will still script in LSL for the time being.
3. LSL will generate Mono bytecode, which will then be run server-side.
Which means:
4. Eventually we will be able to write SL scripts in other languages than LSL. Personally, I’d prefer Python.
5. The more-remote possibility is developing scripts locally and uploading compiled byte-code to SL.
Which leads to these worries:
6. There will be a surge of server-side exploits once Mono is implemented as black-hat scripters download Mono and learn where likely weak spots are to force the compiler to generate bad bytecode. All this talk about heap issues tells me there is something to be found there. This will be much more likely if 5. above is implemented.
7. Eventually the server-side exploits will get patched. But if any of these exploits result in hostile scripts able to transfer Lindens, very bad things will happen to LL. Remember, Lindens and cash are interchangable, and the portion of the EULA that says “we can turn that off any time we want” will not pass legal muster. (I’m not a lawyer. My friend who IS a lawyer who plays SL tells me that once a business has set expectations like that, it becomes the defacto contract… so if LL ever STOPS cashing in Lindens, they’re in for a heap of trouble, no matter what the EULA says.) So LL will be liable for the cash value of any Lindens you lose due to Mono exploits, in the same way that your bank is liable for any money you lose if their account-management website gets hacked.
Therefore:
9. If LL has half a brain, no Linden transfers should be possible through Mono for a very, very long time, until the Mono framework is as thoroughly wrung-out as humanly possible. Nor should Mono-executed scripts be able to instruct other scripts to initiate Linden transfers.
Nine points. Two cents.
January 21st, 2007 at 5:49 PM
And there is no point 8. Nether is there a Rule 6.
January 21st, 2007 at 8:21 PM
Good news. I’m very glad to hear it. Second Life is growing more technically capable all the time. The First look viewers with the improved drawing code have been wonderful toys.
January 21st, 2007 at 9:15 PM
@Nanashe
Mono is an opensource version of the Microsoft .NET framework. In the medium-term, at least, Lindens are working on ways to get LSL to compile into Mono-compatible bytecode, which is capable of being executed several factors faster than the current methodology, and using significantly less resources. This should result in markedly improved sim performance and reliability.
Because Mono can execute any CLR (Common Language Runtime) code, it may eventually be possible to create scripts in outside languages such as C# or VB.Net or Python. This would require Lindens to open up the server-side Mono LSL spec to the community, on their timetable. That phase, if ever implemented, will be down the road a ways.
January 21st, 2007 at 11:13 PM
[...] Babbage Linden: Thanks for the Memory - “With this development, the work on Mono takes another step forwards. We’re currently working on moving script compilation to our new web services platform and once that’s done I can wire in the LSL to Mono compiler, bytecode injector and verifier as web services and then the main pieces of the work on Mono will be done.“ [...]
January 22nd, 2007 at 12:02 AM
Not being a grand high programmer, I have no idea what exactly this means, but it looks like good news all round as far as i understand it. Good job!
January 22nd, 2007 at 1:06 AM
Many already mentioned this but I would really like to see the ability of creating scripts in other languages (LUA would be my favorite, but I’m rather agnostic).
Let’s face it, as a programming language LSL is basically flawed. It lacks a really useful structure (lists are no way a replacement for associative arrays!), comparison between strings is not allowed, the number of cascading if/else if is limited, etc.!
Taken .NET/Mono as a basis, I would rather focus on the creation of a set of assemblies that could be used by many .NET languages.
LSL has to stay to ensure back compatibility but any new script could be written in a more proper language (C#, Python, whatever LL will decide to support the compilation for).
I would not spend time expanding and making LSL a more modern scripting language, there are so many good example for this and many are free (did I mentioned Ruby?).
Jut my 2c.
Rael
January 22nd, 2007 at 1:32 AM
Mono is the key to the future on sl, without it not much to hope for. Warda thisis the future now there is no turning back.
January 22nd, 2007 at 2:22 AM
Mono is nice for playground, but it is not ready to cope with such a large project as SL ! .net could be fine (more versatile, more possibility), but mono is really lagging behind the reference. Plus MS has clearly said : no .net outside Windows ! This means choosing Mono you are limited to mono supported features and can not benefit from .net features
Or this would mean, limiting the supported platforms to Windows only 
The realy problem of Mono is IP and potential legal threats comming from MS. Situation of mono here is not 100% clear. They said they don’t want to attack them, but still hold 100% of IP. Anybody want to rumble with them here ?
This is not a technical limitation but a strategical limitation from Microsoft Corp. And this is quite logical … think of it, would MS be happy if “MSOffice” (assuming it was written in .net) would run on Linux ? Nope
So, did you test the same thing with Java ?
I mean, Java is the original version of .net after all. Core engine would be kept native, but scripts will go Java … sound realy possible.
Java is very stable platform (more than 10 years now), opensource (GPLv2 !) with also opensourced & free powerfull tools … seen Netbeans or Eclipse C/C++ integrated building tools ?
Plus Java is available by default on most computer bought (Apple, HP, Dell …) or can be easilly upgraded if required … (less than 2 MP3 in download size)
Java is realy multiplatform, plus supported platforms are almost everywhere (from phones to mainframes). You have access to all the features from each suported OS .
Java has also strong security models and encriptions mechanism that are required to bring viable business models to SL.
The problem with Mono is that it depends on MS “good will” (IP infridgements, specs publications, …) whereas Java has all specifications open to public (see JCP site) and have specification groups open to participation. This can be interresting if a new specification is required to interract with SL for instance.
The Java6 pluggable scripting engine can make LindenScript pluggable into Java so that existing scripts can interface with “compiled scripts”. Very powerfull.
There are also tons of languages that can be compiled to Java (google to “vmlanguages” for the list). So adding a new one say “LindenScript” should not be “that” complex
Guys at LindenLabs, realy evaluate Java as a script platform, could realy worth it …
January 22nd, 2007 at 2:53 AM
[...] Read‘|’Permalink‘|’Email this‘|’Linking’Blogs‘|’Comments [...]
January 22nd, 2007 at 3:08 AM
Are you looking at having local scripts running on the client/viewer machine, or will all scripts still run on the sim server? It would be good if there was some way to distribute the load, as I guess many scripts are local in nature (eg, huds and attachments).
January 22nd, 2007 at 4:03 AM
RUnning scripts on the client is a security risk. You could download the bytecode and regenerate LSL code from it or inject bad bytecode to be run by the client.
January 22nd, 2007 at 4:17 AM
This is great news, although I think it’s smart to focus on scalability and stability right now. Faster scripts are awesome because it lays the groundwork for better physics and more responsive objects, but before scripts can be run, the objects has to be transferred from server to client. That’s where it seems you’re having DB load problems, especially when the object isn’t cached on that Sim.
I think the solution is to implement the ability to retrieve resources such as textures and sounds (maybe even objects some day?) externally through TCP/HTTP on user’s servers. Maybe the “sim-caps” project is going that way, but I really think you need
to have less UUIDs created on your servers. External resources are a possibility, but I also think there’s room for improvement on how you create and maintain UUIDs. For example, it’s extremely wasteful that I have over a hundred versions of something I was working on in-game, when I should only have one. If only I had a way to back up my data locally instead of “Taking” the object… then you could garbage collect those useless deleted objects that I never gave to anyone else, which would mean hundreds of less UUIDs for you (just on that one project). I think less UUIDs are the only way you’ll scale past the 6 figure concurrent user threshold.
This is just my opinion, you obviously know what you’re doing given the crazy stuff you’re doing with Mono… so keep up the good work.
January 22nd, 2007 at 5:57 AM
[...] Articolo in blog di Linden Lab [...]
January 22nd, 2007 at 6:36 AM
My major concern is seeing that the transition does not Bork all the existing scripts… now that’s a nightmare.
January 22nd, 2007 at 6:37 AM
thats some awesome news right there! if mono really shows a 100-150times faster execution of scripts, this will provide a major boost to sim performance
and to those who worry themselves silly:
Mono is NOT a new scripting language. its what the LSL bytecode will run on, a platform, so to say. and I doubt it will yield any exploits. Mono is by far more mature and advanced than the current LSL VM. I rather predict major speed increases along with better extensibility of the current LSL commands.
Im eagerly awaiting this new language and secretly hope that LSL might get a few new nifty commands in the process
January 22nd, 2007 at 6:53 AM
Question: will mono-compiled scripts use less memory (if it’s the same scripts) as now?
Another question: Will you increase the memory for 1 script (why is it so low anyway? and why so hard to increase???)
January 22nd, 2007 at 8:49 AM
This is awsome! Now if I only had the slightest clue what you were talking about, it would be even MORE imprssive.
I do hope that soon you will be able to interface the whoozit with the whatchamadoojiiger, thus completing the spitzensparken!
/me blows a fuse
*PIFF*
January 22nd, 2007 at 10:12 AM
@Nanashe:
The CLR usually performs bytecode verification to avoid the types of issues you reference. The Lindens and the Mono team are both aware of these issues and appear to be working towards implementing bytecode verification into the Mono runtime. The Lindens could still go live with a solution where it is not directly incorporated into the Mono runtime. For example, they can use PEVerify.exe on a Windows box to verify the assembly before loading it into Second Life. There’s a page on the Mono website that addresses both the ideal solution and workarounds:
http://www.mono-project.com/MonoSandbox
January 22nd, 2007 at 11:36 AM
1. The current system does not use Mono, They are just testing it.
2. LSL will run faster when they use Mono since it’s not an interpreter, but a compiler that re-compiles the bytecode to the native processor.
Remember the “MS QuickBasic threaded P” compiler did the same thing and was a lot faster than “GW basic”.
3. Earlier they said that the LSL compiling will be sim side and you won’t be able to upload Mono bytecode so we are safe.
4. This will allow for more efficient LSL calls since LSL will be able to internally use pointers. So llListReplaceItem will be possible.
5. I am hoping they reduce the script overhead since currently each script uses script time even if it is not doing anything.
It’s hard to get lots of programmers to work on one task at the same time and this looks like one of those things where a separate team is keeping busy and progressing forward.
January 22nd, 2007 at 11:37 AM
Moving the mono compiler to a “web services platofrm” kind of implies that script compilation will be done by linden labs, not the client, which makes the verifier a non-issue… the client would not be uploading bytecodes to SL.
I’ve been digging through indra.l, indra.y, and lscript_tree.cpp and I think I have a handle on fixing the most annoying parsing bug in LSL, as well as allowing constant expressions in globals. If LSL compiletion is moving away from the client is there really much point in me continuing this?
January 22nd, 2007 at 1:36 PM
What’s the point? Another weekend, and now a Monday with over 26k users, and the whole thing is slow, tps are broken, inventory is loading at like 6 iems every 30 seconds…
January 22nd, 2007 at 1:47 PM
What is it with these CRASHES to DESKTOP? this past weekend…i and friends we crashed non stop - specially when doing nothinh - when standng still.
You LL’s may want to check on this - because my new ATI does not like your Crashes.
January 22nd, 2007 at 2:38 PM
Well Gala ATI cards dont like SL that much because SL is based on open gl and not Direct X. You have have problems people with Nvidia hardware dont but at the same time it could be other factors. I assure you its something on your end because i’ve used the SL client on both windows and Linux with no problems except for the db issues on friday. Less you use the Mac client which im unsure about. Anyways im looking forward to the switch from LSL2 VM to Mono because quite frankly better faster and frankly more stable.
From what i’ve heard on all the news of it since they announced it im rather excited :).