Memory Changes for LSL?

Hi all,

I've been noticing some problems with our tools on the SLOODLE project. We haven't moved everything over to Mono yet, as we have a lot of scripts, and haven't had a chance to test the conversion thoroughly yet. However, some of our tools compiled without Mono have started having memory problems (specifically, Stack/Heap collisions).

An example is our "WebIntercom" (connects in-world chat to a web-based chatroom). It used to be able to handle big discussions of 20 or more people easily, but with just 12 people recently, it ran out of memory. Recompiling the primary script to Mono seemed to solve it.

Our "Quiz Chair" tool is having similar difficulties -- it used to handle plenty of questions easily, but now it runs out of memory with just a few.


As such, I'm wondering if there have been any changes in LSL which could be impacting memory in this way? Has the compiler been altered somehow?

Thanks,
-Pedro

it's my understanding that the server allocates 16k for LSL2 VM, and 8k chunks (up to 64k) for mono.

in LSO it was possible previously to use the following hack to preserve memory...

mlist =(mlist=[]) + mlist + newitem.

I believe they've now prevented that particular optimization (or at least they were talking about it in regards to the VM, I can't test if that change is active, since my net is borked to near dial up speed)

the change should break lots of stuff that relied on it to stay under the LSO 16k ceiling.

To be precise, they say this hack is no longer necessary.

Like the warpPos(vector targetPos) function?

well if it is the source of OP's problem (and it may not be, I'm guessing), then I'd say they were full of it.


if it's being used to stay under the memory ceiling and it's close enough to the ceiling that the doubling the 2*list_memory + new_value_memory hits the ceiling? yeah (assuming this IS the problem occurring)

Not necessary with LSL mono. Still usefull with LSO.

However, they are changing/changed LSL mono (might also include LSO) such way that it is not possible to temporarily use more than 64K with mono scripts within a time slice. For example: l = llListSortList(l) - during evaluation of the expression there used to have only one list - but after changes there is 2 lists. (http://wiki.secondlife.com/wiki/User:Babbage_Linden/Office_Hours/2009_03_18). This change might cause problems.

I have a catch-22 with one script that uses warpos and is affected by this:

http://jira.secondlife.com/browse/SVC-3895

So, it is either to not use mono and not have problems or use mono and have problems

should someone want to test, these are (close to) the scripts I used to test the ceiling for LSO scripts pre-mono, using the memory hack described above..

compiled ins LSO (NOT mono)

list gLstTest =[NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY];

default{
  touch_start( integer vNull ){
    while (TRUE){
      gLstTest = gLstTest + gLstTest;
      llOwnerSay( (string)llGetListLength( gLstTest ) );
    }
  }
}

list gLstTest =[NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY];

default{
  touch_start( integer vNull ){
    while (TRUE){
      gLstTest = (gLstTest=[]) + gLstTest + gLstTest;
      llOwnerSay( (string)llGetListLength( gLstTest ) );
    }
  }
}

think I got those right... original script values topped at 160 for the first one, and 320 for the second before they had a collision error

160/320 is what I got.

Note that the "While" needs to be "while" (lower case)

well then unless only certain servers have new code limiting that hack from being effective, it's probably not the culprit....

which makes me wonder what is....

ps, thanks I'll fix that

Don't use mono for that kind of script. Using mono for a script that doesn't use much CPU but does use a lot of memory is just adding extra load to the sim for no good reason.

Mono is not a panacea, it's about 3x as memory-intensive as LSL2 and also requires more server overhead when rezzing, taking into inventory, and crossing sim boundaries.

Which is why my Mehve is still using LSL2... there's no performance difference between Mono and LSL compilation, and it handles sim crossings better with LSL2.