llGetLinkPrimitiveParams() ??

No worries. Back at ya, hon. I still disagree, though..

there sort of is....
keep non-running copies in the root, active copies in the children. set a script pin, and script in a set state false for those... when you need to restart them, use remote load to refresh them as running (although it means they can't have their own survivable memory). the only bad thing is the stupid 3 second delay. give inventory doesn't have that kind of restriction on objects (and only 2 sec on avatars)

even a global set state like the menu option would be nice or better targeted by link number! =\

Ahhh, didn't know the pin was a prim property and not a script property learn something new every day.

You obviously say that with one special case on your mind.
I don't know what that is but I have one on my mind that has the same big script in each linked prim.
In that case the code space being common would matter (I guess).
The data would be different for each prim in the linked set, but that would be the same in both cases: one script per prim or one script per linked set

And keep in mind that there is one other "bad thing". Scripts that are not running are reset and you loose any stored info whenever you cross sim boundaries or the sim is restarted.

I guess it might be unreasonable of me, but the only special case I'm thinking of is that the coder is competent. The data is more of an issue in Mono because it's so much less space-efficient than LSL, so in either case I don't think you can ignore the memory usage of many scripts. And, of course, we know that Babbage is working on establishing quotas for script memory usage.
Uh-uh. The single-script version wouldn't need to maintain a list of all the data, so the concurrent memory use would remain low. Even if the multi-script version doesn't relay data back to a permanent store in the root, AND assigns the list to [] as soon as possible to minimize data use, it has each prim's data getting fetched concurrently so the system as a whole has higher peak memory requirements.

now THAT I didn't know... not running scripts get reset at sim boundaries? seems like that should be a jira, since it's certainly NOT the same behavior as scripts that are taken to inventory.

fortunately for this example, they'd be wiped anyways when remote load feeds in the new copies of the script. of course you'll want your pin number in a safe place to prevent such losses from the main scripts erroring (maybe a hidden property value on a prim, plus an internal calculation)

@Lazink:
actually it was fairly recently I found out myself... although I'm not sure how stable a property it is, since I haven't tested extensively. I've never heard of it being wiped but.... I trust nothing in sl

It is a jira somewhere. Gearsawe Stonecutter noticed that behavior about a year or so ago and mentioned it to me. I had even forgotten it until a discussion a week ago in the scripters mailing list. I was defending that scripts were safe until someone mentioned scripts that were not running. Someone tested and it was confirmed that this still happens.

From what I understand, and most likely miss-reading what you are saying, but current memory usage under the memory limitation system won't matter at any slice of time. From what I gathered, the script will be assigned it's memory by the upper bounds, not the average bounds, and if I remember right we as suppose to be able to assign that upper bound limit with new functionality that will be released with the memory pool system, so we can artificially create that upper bound for each script to not exceed.

Admittedly, the consequences of using up memory are worse, but both time are very important.

I know what you meant, and you knew what you meant, and so do all the posters on this thread, but just to clarify for onlookers: replace "scripts that are taken into inventory" with "scripts in objects that are taken into inventory".

I didn't know that either. Learn something every day!

Lazink, you're mixing two issues.

First, LL says they'll give us a way to request specific amounts of space. I don't know the details, though I can imagine reasonable scenarios. However, this won't be a requirement, so scripts that don't use it aren't affected by it. Furthermore, these limits are likely to be per-script, not per-object, so they wouldn't affect things like the hair resizer script.

For existing scripts, the peak usage will definitely matter: the scripts that ask for memory when the parcel's limit is reached will get faults (similar to today's "stack/heap" error). Each parcel essentially has a pool of memory, and when that memory pool is empty, it's empty.

Meanwhile, Jane Bling standing around with her 254-prim resizable hair that she's NOT resizing will consume significant memory for a feature not being used. So, other scripts with reasonable memory usage get stack-heap faults because Jane's in the parcel. Even if each script consumes 1K of memory, that's 254K of memory for no purpose.

With a resize script based on llGetLinkPrimitiveParams(), Jane's hair will only have one script and will have far less impact on the region's memory limit.

And the good news is that hair makers will be sent the message loud and clear to make their hair low-impact on parcel memory.

No, they won't get stack-heap faults. They will simply fail to rez, or if they're moving objects (teleporters, vehicles, avatars with scripted attachments) they will not be able to enter the parcel. Jane Bling may even find herself bounced at the region boundary if she tries to wear her high-prim hair into a busy region.

I could have sworn that avatar vs parcel memory usage would be separate. From what I've been told and read, Avatars themselves will have their own memory. So if a parcel uses lets say 254k of it's allotted 512k memory, and Jane Bling comes along to that parcel, with their hair resizer, that takes up 356k memory (just throwing arbitrary numbers), it will NOT cost against the parcels 512k memory pool, instead Jane Bling has a memory pool of say 512k, and is using 356k of that for their hair, limiting them on other attachments that may use memory.

This is what I understood how it is going to work, that Avatar memory pool and parcel memory pool will be kept separate from each other.

I'm way out of my depth here coding-wise, but don't scripts use varying amounts of memory from moment to moment depending on what they are doing? What would happen if a scripted object is permitted to rez or enter the parcel based on a low instantaneous memory footprint, and subsequently does stuff which causes it to consume (request) vastly more memory?

That is one of those questions that we really don't know the answer to, as I don't think LL does either. So it depends on how exactly they implement this, they may put it on the creator to request a certain block of memory at the beginning of a script, and that is your block of memory, they may not, and if the script goes over, they may allow it, but have something that if it stays over a certain amount of time, something will happen. I have yet to see exactly how they will handle it. I could see them even not implementing anything, and if the script uses up all the memory pool, it shuts down silently, forcing the creator to take the responsiblity of knowing exactly how much memory the script will use.

Well for most of it we are really going to have to wait for the UI to hit Aditi, just like the MONO rollout. Once that happens, then it is going to be a delicate balance between feedback from the test community and internal LL discussions. In other words, they don't really know yet either.

But from the little bit that has been said so far, I was under the assumption that an object or script will be assigned a value. That assumption is based on the one statement that objects will display thier memory usage in xstreet.

Jesse's Super Duper Multi-Hud uses 270k of memory. Now most of the time that hud uses maybe 200b in it's inactive state. If an AV is allowed 500k and I am already using 300k, I would not be able to use the hud at all until I detached something else.

But then again we know what happens when someone assumes something.....................

Oh yes, definitely. A common situation is that a script needs to use list entries temporarily during initialization or some function, then that gets discarded. Under LSO you can't see that the memory is no longer in use, because llGetFreeMemory likes to stay put once a new ceiling is set. Under Mono you can get a glimpse into this by crossing to another region, that causes the marker to be reset.


Nothing has been set in stone yet, but the idea is that existing scripts will continue to use the 16K/64K limits they have today. New scripts will have a malloc-like function so that they can request a larger or smaller limit. It will be the 16, 64 or custom limit that will decide that you can rez, not the portion of that you are currently using.

LSL scripts always use 16k no matter what they're doing. Mono scripts use 8k to 64k in 8k chunks, and if the script is not compiled with a lower limit all Mono scripts will be treated as if they were 64k by the quota system. If the script is compiled with (say) an 8k limit, then it will get an overflow when they hit 8k regardless of the sim quota, and they will be counted as an 8k object in figuring sim, agent, and parcel quotas.

That's one suggestion. How the quotas will be calculated and what they will be won't be determined until after the instrumented server has been in operation a while.

this was my understanding as well... with an exception to region level, which would not be a separate pool.

so the scenario SEEMS to be that parcels will have a guaranteed limit on their own, and avatars will have a shared limit on the region. so Jane Hair could be bounced at the region border when moving to a busier region (possibly just have certain scripts disabled).... how that'll operate with teleports etc is unknown. it might create a first come first serve problem, or a dynamically working/not-working situation for all avatars on the sim.

because mono uses a shared code space it'll probably mean a bonus to standardization of scripts on the sim, and a further bonus to component script models. my plug and play styled avatar attachments are looking better all the time. it's also likely going to mean that sims that are heavily subdivided are likely to have less available script memory (due to different people using different scripts for similar effects). that'll probably put a crimp in new ideas for old problems when residents catch wind of it, and start using a single specific script for the same effect (which could hurt future optimization/innovation).

Since memory is allocated at runtime, I don't see how this is possible. I can imagine that once the limit is reached, things will fail to rez. But I also believe that things will get stack-heap errors if they're already running and then request more memory.

I believe you're right, and my point applies in either case: scripters and content creaters will get incentivized by residents (the market) to make products memory-efficient, which is not the case currently.

I doubt they'll do what you suggest.

They need to support 'legacy' scripts, which do not request memory at startup. So, for things to work this way, they'd need to allocate 64K from the memory pool for every Mono script, regardless of how much memory it actually uses. That will eat up the parcel memory pool too fast to be workable, IMHO.

I stand corrected.

Regardless of the details, my original point still stands: content creators will have a big incentive to be efficient with memory, and that's a good thing for SL in general.