[sldev] Script/Parcel/Memory Limits - Memory Limit Configuration

Tigro Spottystripes tigrospottystripes at gmail.com
Fri Dec 18 01:21:49 PST 2009


wow, i usually re-read my emails before sending them and do ortographic
corrections, i have no idea what happened there 0.0

sorry :/

lemme try it again


    The problem with a fixed maximum guaranteed memory per script is
    that it
    doesn't add a limit for more than one script, so several scripts could
    be using the minimum guaranteed and not being capped.

    My idea is to have a fixed per meter and per avatar maximum guaranteed
    memory, anything above guaranteed. Scripts using more than that are out
    of the safe limits.

    We Need somthing like llGetSimFullMemory, llGetSimFreeMemoy,
    llGetParcelFullMemory, llGetParcelFreeMemory, llGetOwnerFullMemory and
    llGetOwnerFreeMemory. And i like the idea of an event to be triggered
    before the script either looses some of it's avaiable memory or is
    about
    to be shut down if it doesn't start using N less bytes of memory,
    somthing like:

    less_memory(float bytes_to_loose)


    The sim waits for the event to end for a second or so and if it
    doesn't end
    in time or if after that the script still hasn't lost enough bytes
    in it's ram footprint the sim will shutdown the script (perhaps save
    the
    script state of not running scripts on disk and not on ram?)



there, once again sorry for the messed up msg :\







Melinda Green escreveu:
> That seems like the same thing that I just said except that your text
> and grammar are so messed up that it is hard for me to understand
> exactly what you are saying.
> -Melinda
>
> Tigro Spottystripes wrote:
>> The problem with a fixed maximum guranteed memory per script is that it
>> doesnt' add a limit for more than one script, so several scripts could
>> be using the minimum guarantted and not veing capped.
>>
>> My idea is to haev a fixed per meter and per avatar maximum guaranteed
>> memory, anything baove guaranteed. Scripts using more than that are out
>> of the safe limits.
>>
>> We Need somthing like llGetSimFullMemory, llGetSimFreeMemoy,
>> llGetParcelFullMemory, llGetParcelFreeMemory, llGetOwnerFullMemory and
>> llGetOwnerFreeMemory. And i like the idea of an event to be triggered
>> before the script either looses some of it's avaiable memory or is about
>> to be shut down if it doesn't start using N less bytes of memory,
>> somthing like:
>>
>> less_memory(float bytes_to_loose)
>>
>>
>> The sun wauts tgat evebt ti ebd fir a secibd ir si abd uf ut diesb't ebd
>> vefire tgatm ir uf after that the script still hasn't lost enough bytes
>> in it's ram footprint the sim will shutdown the script (perhaps save the
>> script state of not running scripts on disk and not on ram?)
>>
>>
>>
>>
>> Melinda Green escreveu:
>>  
>>> Perhaps a hybrid design might make for a reasonable compromise between
>>> predictability and flexibility. Something like hard lower memory
>>> limits that scripters can count on always being available, plus the
>>> ability to request and receive provisional amounts beyond that which
>>> might get yanked back at any time. If you go beyond the safe limits,
>>> you take your chances. There may even be more gentle ways to deal with
>>> these worst-case situations, for example by creating an LSL event that
>>> informs scripts when they are about to lose some or all of the
>>> provisional memory that they are using, giving them a chance to get
>>> back under a safe limit and avoid getting shut down.
>>>
>>> I suspect that Qie Niangao is right that some non-trivial optimization
>>> logic is called for here. To me the situation feels like operating
>>> system design. In many ways the simulators *are* simple operating
>>> systems. Perhaps talking with some Linux kernel developers might
>>> identify some libraries that can be used to manage script resource
>>> allocations. I don't know because OS design is not my field but I
>>> suspect that there are no simple solutions to this problem and that it
>>> would not be smart to try to reinvent its solutions.
>>>
>>> -Melinda
>>>
>>> Ambrosia wrote:
>>>    
>>>> But in your example, the script uses the max of the sim til the avatar
>>>> comes in. The script will crash, as the avatar takes his own share of
>>>> memory, and the script suddenly has less than it actually uses (not
>>>> what it -could- use but doesn't).
>>>>
>>>> Scripts -will- be able to check available memory, that much has been
>>>> stated, and they reserve additional memory they need with another
>>>> function, but that available memory should not depend on factors of
>>>> what's going on outside the parcel or on other avatars aside of the
>>>> own.
>>>>
>>>> Quite frankly, the only thing that makes sense for scripters and
>>>> content creators are hard numbers they can work with. Fixed memory
>>>> amounts. Every 512sqm parcel should always (normally) support X mb
>>>> max. Every avatar should normally support Y mb max. A solid api to
>>>> build scripts upon. Available memory depends on the scripts already
>>>> attached to the -same- avatar or on the -same- parcel, but a parcel's
>>>> or avatar's memory should -not- be dependant in any way on external
>>>> factors like other avatars or parcels. It makes things unreliable,
>>>> unpredictable.
>>>>
>>>> On Thu, Dec 17, 2009 at 16:10, Tigro Spottystripes
>>>> <tigrospottystripes at gmail.com> wrote:
>>>>  
>>>>      
>>>>> There should be a way for scripts to check how much memory is
>>>>> avaiable
>>>>> int he pool for the sim, and for the parcel, and also how much memory
>>>>> the script will be limited to under a worse case scenario,
>>>>>             
>>>> _______________________________________________
>>>> Policies and (un)subscribe information available here:
>>>> http://wiki.secondlife.com/wiki/SLDev
>>>> Please read the policies before posting to keep unmoderated posting
>>>> privileges
>>>>
>>>>         
>>
>>
>>   
>



More information about the SLDev mailing list