As far as I understand it a script (the item you manipulate in-world) is a
bytecode (a compiled version of your code without the comments, the spaces
and the returns) loaded into the sim, plus its simple, constant-size
variables (integer, floats), all of which forming the stack. Then you have
all the varying-size variables, namely strings, keys and lists, which all
form the heap.

The 64k limit concerns the sum of the bytecode, the stack and the heap. The
size of the two former is fixed and determined at compile time, while the
size of the latter is variable.

Someone please correct me if I'm wrong, this is experience talking, I do not
have access to the server-side code of the script handling.


On 7 March 2010 13:11, Tony Dodd <tony.d...@btinternet.com> wrote:

>  May I ask a probably dumb question here? It's probably been answered but
> I can't find the answer now.
>
> Presumably a script uses two resources, the byte code in its assembly and a
> slab of memory allocated for its stack/heap. And am I right that the former
> can be shared between multiple copies of a script whereas the latter would
> have to be allocated separately to each script?
>
> OK, the question is, does the 64K limit refer to both of these together or
> just to the stack/heap? If I have a mono script that is quite large but
> doesn't allocate any lists, will each instance of that that runs be using up
> 64K of memory?
>
> If there's an obvious place I should look I apologise but without knowing
> this I find it hard to assess how much impact memory limits will have on my
> own scripts.
>
> Maldoror Bowman
>
>
>
>
>
> _______________________________________________
> 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
>
_______________________________________________
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

Reply via email to