Page 1 of 2
Interesting script behavior with huge implications
Posted: Wed Sep 02, 2020 4:23 pm
by RezMela Apps
Hello everyone,
This is an intriguing puzzle. Can you help us figure out the underlying likely cause for the difference in behavior of the script below (it's only a few lines)?
The implications are deep for applications using lists (which is a basic data structure).
How to reproduce?:
1. Put the mysterious script below in a prim
2. Touch the prim to populate the list l
3. and Restart region under two different conditions
condition 1: size = 10 //size of list
condition 2: size = 10000 //size of list
4. Note time of region restarted.
Observation:
The set text in state_entry shows the time the script started.
With a size of 10000, the time displayed is that of the current region restart (
that is the script got reset),
but with a size of 10, time of region restart doesn't change (
that is the script was not reset) even if the region was restarted.
In short, the script resets depending on the size of the list. This is a critical issue for data driven applications that run on Kitely. We are trying to hard to push the envelope a little bit further. I know there are many talented scripters on this forum, your help and insights will be deeply appreciated.
Intriguing script follows
Code: Select all
list l = [];
default
{
state_entry()
{
llSetText("Started at " + llGetSubString(llGetTimestamp(), 11, 18), <1, 0, 0>, 1);
}
touch_start(integer n) {
integer size = 10000; //10000 resets script, 10 does not
integer i;
for (i = 0; i < size; i++) {
l += [ "sdjkahfgfdaskjghfadsgkhj", "kljhsfdahkjldfshlkjhfdslhlfdsh", 234987432 ];
}
llOwnerSay("done");
}
}
Ramesh
Re: Interesting script behavior with huge implications
Posted: Wed Sep 02, 2020 5:19 pm
by John Mela
As far as I've been able to determine, the issue is that scripts are reset on region restart if their data occupies above a certain amount of RAM. Exactly how much that is would be time-consuming to determine, and would be of little use in practice because llGetUsedMemory() etc are not currently implemented in OpenSim. Obviously, real scripts that are using this amount of memory are likely to be doing so in a variety of different variables rather than a single list, and to measure the size of used memory at run-time in such an application would be a messy job.
It goes without saying that this issue limits greatly the capabilities of the affected scripts.
Re: Interesting script behavior with huge implications
Posted: Thu Sep 03, 2020 8:05 am
by Oren Hurvitz
OpenSim has a limit on the maximum of script state: it's 0.5 MB. This particular script, when it creates 10,000 strings, uses 3 MB.
It looks like OpenSim doesn't enforce this limit at runtime (a potential problem), but does enforce it when the region is restarted.
Re: Interesting script behavior with huge implications
Posted: Thu Sep 03, 2020 8:06 am
by Oren Hurvitz
If you need to store a lot of data then perhaps using Notecards would work.
Re: Interesting script behavior with huge implications
Posted: Thu Sep 03, 2020 3:52 pm
by John Mela
Thanks, Oren.
Unfortunately, the data is very dynamic, not at all suitable for serialised notecard storage. And besides, I don't believe it's possible to create a notecard without first storing that data in RAM in its entirety.
Would there be any possibility of increasing that limit? 500KB is really not much data these days for any kind of serious application.
Also, would it be possible for a script to monitor its RAM usage, such as with llGetUsedMemory() on SL?
Re: Interesting script behavior with huge implications
Posted: Thu Sep 03, 2020 5:43 pm
by RezMela Apps
@Oren, is there a document somewhere where this limitation is described
Oren: 'OpenSim has a limit on the maximum of script state: it's 0.5 MB'
I want to understand the why of this constraint.
I tried googling for info but could not find anything.
Ramesh
Re: Interesting script behavior with huge implications
Posted: Thu Sep 03, 2020 6:46 pm
by Graham Mills
John Mela wrote: Thu Sep 03, 2020 3:52 pm
Thanks, Oren.
Unfortunately, the data is very dynamic, not at all suitable for serialised notecard storage. And besides, I don't believe it's possible to create a notecard without first storing that data in RAM in its entirety.
Presumably it's script-dependent but I'm reasonably sure you can have the data for a single notecard in RAM before writing it to the (finite-sized and hence possibly one of several) notecard?
Re: Interesting script behavior with huge implications
Posted: Thu Sep 03, 2020 7:12 pm
by Oren Hurvitz
John Mela wrote: Thu Sep 03, 2020 3:52 pm
Would there be any possibility of increasing that limit? 500KB is really not much data these days for any kind of serious application.
Also, would it be possible for a script to monitor its RAM usage, such as with llGetUsedMemory() on SL?
I've talked this over with Ilan, and we decided to increase the limit to 5 MB. That's going to happen in the next few days.
Please note that if you take advantage of this increased capacity then you also increase the risk of encountering script problems:
1) If you have many scripts that use a lot of memory then you might run out of memory in OpenSim (I'm talking about the 1 GB to 4 GB of RAM that OpenSim gets).
2) If your system (RezMeLa) actually uses this much memory then it probably also creates a very large number of prims, and it might time out when creating or deleting them.
Regarding implementing llGetUsedMemory(): that's not something that we're going to do, sorry. It's a lot of work for something that's rarely used, and there are other priorities that we want to work on.
Re: Interesting script behavior with huge implications
Posted: Thu Sep 03, 2020 7:13 pm
by Oren Hurvitz
RezMela Apps wrote: Thu Sep 03, 2020 5:43 pm
@Oren, is there a document somewhere where this limitation is described
Oren: 'OpenSim has a limit on the maximum of script state: it's 0.5 MB'
It's not documented, I just saw this in the code. It didn't even have a constant...
The limit is actually not in memory, but instead it's checked when the script's state is loaded from disk. I.e., it's the size of the disk file; not the size of something in RAM.
Re: Interesting script behavior with huge implications
Posted: Thu Sep 03, 2020 10:14 pm
by Ramesh Ramloll
@Oren @Ilan, you guys are awesome. Thanks for responding so fast. We will keep you posted after testing. We are really happy about this.