[opensource-dev] Script Memory Limits UI

[Lear Cale]

It would be nice if everything were free, too.

The issue is memory *allocation*.  If a script only uses 16K but is
allocated 64K, that 64K counts against the server's actual memory
allocation limit.

So, cool, wouldn't it be nice to only allocate what is actually
requested?  Well that implies rewriting a lot of code to use memory
differently, and requires frequent reallocation of memory (as the
needs grow or shrink).  There is a real cost to this, in terms of
programming effort and in terms of runtime costs.

Until now, script memory has seemed to be a free lunch.  Well, the
free lunch is over, and we'll have to deal with it.  I won't believe
that it's feasible to simply "report the actual memory used" until
someone who really understands Mono memory allocation and our
scripting language's arrays (the main memory users) says that there
actually is a feasible solution along these lines.

Change causes upset.  This will be an issue.  IMHO, though, failing to
address the problem would be worse.

Regards
Jeff

On Sun, Mar 7, 2010 at 6:20 AM, Marine Kelley <marinekelley at gmail.com> wrote:
> Well we have two mutually exclusive solutions here.
>
> Either Mono scripts are given a hard memory limit that we (the scripters)
> can change within the scripts, with all the overhead work that it implies
> (i.e. modifying hundreds of scripts before issuing an update, and having to
> know upfront how much memory will be taken exactly), which means that in
> regards to the scripts memory usage UI, the script will use exactly as much
> as the limit it has requested, no matter whether it really uses it or not.
> This gives wasted memory and false information.
>
> Or, Mono scripts are given a hard memory limit that we cannot change, and
> they report exactly as many bytes as they use at any time. But we shouldn't
> be able to change the limit ourselves, because it wouldn't make sense to do
> so, it would only be restraining ourselves if we set less than 64k, and
> wasting memory space if we set more than 64k.
>
> In both cases, the question of whether the script crashes when reaching the
> limit or not is not related.
>
> I seriously, and I mean seriously, think that choosing the first option is
> going to hurt the established scripters very badly, and therefore the grid
> as a whole. To me scripts should report exactly as much memory as they use,
> not more, and should not require the scripters to modify them to report
> something that could be computed by the sims more accurately anyway.
>
> Of course it is tempting to tell the scripters "you can now decide how much
> memory to allow, and that way you are certain it will report the amount you
> have set", as much as it is tempting to shift the workload of allocating
> script memory onto the scripters since LL can't seem do it.
>
> Remember, we are now going to have limits on a service that didn't have them
> before. For the same price. All in the sake of stabilizing the grid. Ok for
> me. This will already hurt scripters who will have to adapt bad scripts. But
> now we are told we are going to also adapt good scripts as well ! I repeat,
> this is unacceptable.
>
> Marine
>
>
> On 7 March 2010 03:02, Frans <mrfrans at gmail.com> wrote:
>>
>> As for the dynamic vs fixed memory usage. Of course it would make sense to
>> have dynamic memory usage, but I haven't seen a response yet on how to solve
>> the problem that Kelly described, about scripts suddenly running out of
>> available memory to use, when they fill up lists with info, etc. And break
>> because of it. Or is this considered not to be a big problem?
>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>