Mono script memory checking changed

LL warned us that they'd be changing the way memory usage is checked for Mono scripts.

I believe that they have implemented this in the 1.30.2 server rollout, which happened on Oct 14.

Anyone else seeing this?

Here's what I observed. Before the rollout on Oct 14, MLPV2 beds with prototype scripts ("optimized" ones, version 2.4p, which never worked correctly and so isn't in any products) showed lots of free memory -- far more than the pre-optimized scripts. After Oct 14, these same objects would get a "stack-heap collision" error on reset.

The unoptimized scripts didn't crash, and show *roughly* the same amount of free memory as before the rollout, but I don't keep records so I can't make careful comparisons.

What's the difference? The "optimized" version uses a single list rather than 4 lists to hold position data. The use of 4 lists dates back to LSL, and got around the issue that modifying a lists needs double the space the list takes (one for the original/source and one for the nodified destination copy).

This use of 4 lists wasn't necessary for Mono. When Mono first appeared, I compared using 4 lists to 1 and didn't see a major difference, so I left the code as it was. More recently, Lizz saw a huge improvement using just one list, so I tried it myself and released that to the beta testers as MLPV2.4p. Two days later the rollout happened and MLPV4.2p items that worked prior to the rollout failed quite miserably after, with stack-heap collision. Reverting the "optimization" made the problem go away.

What's the change in memory limit checking?

In Mono, memory limits were only checked when the script yields the processor (returns from a handler or calls a function that delays). LL told us they'd change this to check it on every LSL call. They felt this was a necessary part of the fix to avoid scripts using too much memory and causing server thrashing. I believe it's been available on the beta grid for quite a few months now.

So, take note, and check any memory-bound Mono scripts with the new server.

Perhaps I'm wrong; I didn't do a specific check to verify my hypothesis. I may do so soon. But, when I made the change to 1 list from 4, I expected it to cause problems if they instituted the new Mono memory check, and darn if it didn't blow up in my face 2 days later.

Has anyone else seen this or been able to confirm it?

I can't confirm it on Mono, but I have some LSL scripts that have just started exhibiting simiilar behavior. Haven't had time to dive deep though, so it may be external. (That'll teach me to allow server updates to go by between QA and release.)

I haven't but I also haven't been in-world much lately and rarely script stuff that pushes SL script limits or does timing-sensitive things..

Little surprised they change to do it after every llCall. Seems like they'd be better off doing it after things like list/string changes instead of, say, a llGetPos.

Odd, Jack -- if it involves LSL, then it's not what I assumed it is, but something different.

Meade, that's just the way they described it at a very high level. It could be that they're doing it in a common part of the function callling sequence itself, so it would apply to all functions. If not, then you're right, it would make sense to be more selective, and perhaps they are.

Oh. Fair enough then.

Just to avoid people heading off on tangents, let me emphasize I haven't validated this. But it seems to have appeared between Oct 12 and Oct 18.

I'm not sure what's going on, but I do know that a script that was running for the last week with Free memory of 15232 immedately after a reset has aroiund 2k less today with no chages in the code. And since I'm running close to the limits after I do everything it now crashes!

If I havent changed anything, then somebody else "up there" is

Bones

I don't know about the issue in depth but recently I have been working on a very heavily loaded XPOSE item with just over 500 poses and that uses Mono scripts. I went away for about ten days from the 10th October and when I came back to work on it earlier this week I found that the same item was failing to synchronise animations properly, which is one of the features I really appreciate in XPOSE.

Also I have had Mono scripted windows, each using several parts, that were working absolutely fine for quite a few months now. Thursday I found that the panes would not raise with the frames when clicked to open and the flexi parameters on the curtains did not change as they are scripted to do. I was surprised because the scripts use linked messages and I understand that's the most efficient way to communicate listens within a linked object.

Mind you, I still have a few 'legacy' doors around my place that are scripted in LSL to open on collide and they were a complete non-starter at the same time on Thursday. I never noticed them give that kind of trouble in the two years I have used them.

This is consistent with what I'd expect from the proposed change for Mono memory checking. Thanks for the additional data point.

Ephraim, none of the examples you cite seem related. But then, one never knows. Thanks for the input in any case.

Fair enough, Lear. I really don't have much of a notion what goes on under the hood at all.

However, I would say that between the latest server roll out and the new viewer release, SL is much less stable for me. I crashed three times last night, which is something I haven't seen happen in a hell of a long time. The visuals frequently freeze for short periods and I'm sure that it isn't my system which I had overhauled a few weeks back with a Quad CPU, a new motherboard, an nVidia 9800 GT graphics card, all the latest drivers and as much RAM as I could get my freshly installed Windows XP system to accept. Everything was going great guns before I went away on the 10th and all but one other of my programs are still going strong.

Jeez, seems I can't leave the SL house for a minute.

I have a relatively simple script to rez a demo item in my shop. For over a year, I've never seen it malfunction. Since the last server rollout, however, it fails approximately 25% of the time. I haven't found a solution, and it's been driving me crazy.