Difference between revisions of "LlGetFreeMemory"

From Second Life Wiki
Jump to navigation Jump to search
(same as llGetUsedMemory: a micro sleep can ensure stable results)
 
(21 intermediate revisions by 11 users not shown)
Line 1: Line 1:
{{LSL_Function
{{LSL_Function
|func_id=225|func_sleep=0.0|func_energy=10.0
|func_id=225|func_sleep=0.0|func_energy=10.0
|func=llGetFreeMemory|sort=GetFreeMemory
|func=llGetFreeMemory
|return_type=integer
|return_type=integer
|func_footnote='''BUG:''' Instead of returning the free space it returns the amount of free space that has ''never'' been allocated by the heap (historic lowest heap pointer minus the stack end pointer). This means that the heap will appear to never shrink in size (when in fact it does grow and shrink to fill the free space).
|func_desc
|func_desc
|return_text=that is the available free space for the current script.
|Return_text=of the number of free bytes of memory the script can use.
|spec
|func_footer
|caveats=*The return of this function can be wrong.
|spec=
**[[User:TxMasterG Ping/llGetFreeMemory|Example]]
This function's behavior is dependent upon the VM the script is using. [[#Mono|Mono]] is the new VM, [[#LSO|LSO]] is the old VM. The big difference between Mono and LSO is that Mono scripts run faster and can utilize four times more memory.
 
===Mono===
 
In Mono the value returned is the amount of free memory available to the script prior to garbage collection being run. This means that memory that is awaiting garbage collection counts against the scripts 64KiB allotment. In addition to this, Mono does not enforce the memory restrictions as strictly as the LSO VM did{{Footnote|http://www.langnetsymposium.com/2009/talks/17-JimPurbrick-SecondLife.html}} (with LSO it was <u>impossible</u> to exceed the 16KiB memory cap), consequently it is possible to utilize more of the free memory{{Footnote|In LSO, all types are immutable, every operation results in Heap values being duplicated, meaning <code>a = a + a;</code> resulting in 3 values of |In LSO, all types are immutable, every operation results in Heap values being duplicated, meaning a = a + a; resulting in 3 values of }}.
 
===LSO===
 
In LSO, the value returned by this function is the amount of memory that the Stack can use of the Heap has yet to allocate for itself.
 
The LSL memory space is divided into four sections: Byte-code, Stack, Free Memory, Heap. Free Memory isn't an allocated block of memory, it's just the space between Stack and Heap. The size of all four sections combined is 16384 bytes (16KiB).
 
[[String]]s, [[list]]s and [[key]]s are stored in the Heap. Heap pointers (for [[string]]s, [[list]]s & [[key]]s), [[integer]]s, [[float]]s, [[vector]]s and [[rotation]]s are all temporarily stored in the stack as the script executes.
 
As the script executes the Stack grows and shrinks in size depending upon the complexity of the expressions being executed. Likewise the Heap grows as the script executes but unlike the Stack, it never shrinks in size. When there is no free memory left for Stack or Heap to use they collide and a Stack-Heap Collision error is thrown causing the script to crash.
 
The Heap can become fragmented and blocks of memory in it can become unusable (due to their size). There is no defragment function{{Footnote|Due to the design of the LSO VM, a defragment function is impossible.}} but there are scripting techniques that can be used to reduce fragmentation.
|caveats=
*The number of free bytes the Heap can use may be greater but not less.
*"''the number of free bytes of memory the script can use''" means that if a memory limit is set (via [[llSetMemoryLimit]]), this function will report the free space between the script's current memory usage and the defined memory limit, '''not''' the uncapped memory limit.
|constants
|constants
|examples=
|examples=
<pre>
Calling [[llGetFreeMemory]] can look like this:
// To show usage of memory by a script, take the free memory from 16k
<syntaxhighlight lang="lsl2">
llOwnerSay("Script uses " + (string)((16384 - llGetFreeMemory())/1024) + " kBytes");
llOwnerSay((string)llGetFreeMemory() + " bytes of free memory available for allocation.");
</pre>
</syntaxhighlight>
|helpers
|helpers
|also_functions
|also_functions=
{{LSL DefineRow||[[llGetUsedMemory]]|}}
{{LSL DefineRow||[[llScriptProfiler]]|A more advanced function for analyzing script performance, and can also measure memory usage over time.}}
{{LSL DefineRow||[[llSetMemoryLimit]]|Define a memory limit (lower than the maximum for the appropriate VM).}}
|also_events
|also_events
|also_tests
|also_tests
|also_articles
|also_articles=
|notes=Because of the implementation of this function it's usefulness is limited. It has been stated that when the LSL VM is moved to [[Mono]] that this function will work properly.
{{LSL DefineRow||[[LSL Errors#Script_run-time_error:_Stack-Heap_Collision|Stack-Heap Collision]]|[[LSL Errors|LSL Error]] caused by the script running out of memory.}}
|permission
|notes=The amount of free memory is updated only at the start of a server frame, meaning the values from this function can fluctuate. To ensure stable values, use a single-frame sleep, e.g. [[llSleep]](0.01) before the call to llGetFreeMemory.
|negative_index
|lso=This function does not count free memory, and the name of this function makes this function difficult for people to learn. People say this function may be redefined or superseded by another more useful function when the LSL VM moves to [[Mono]].
 
We can concisely specify [[llGetFreeMemory]] in the context of the classic Unix model for a parallel task/ thread/ process. Think of the task of the script always holding 16384 bytes (16 KiB). Let the byte code and then stack grow up from the bottom, let the heap grow down from the top. [[llGetFreeMemory]] then returns the "historic lowest heap pointer minus the stack end pointer".
 
llGetFreeMemory does not count the bytes freed, [[llGetFreeMemory]] instead counts all the bytes never yet used.
|cat1=Script
|cat1=Script
|cat2
|cat2=Memory
|cat3
|cat3
|cat4
|cat4
}}
}}

Latest revision as of 12:44, 9 October 2023

Summary

Function: integer llGetFreeMemory( );
0.0 Forced Delay
10.0 Energy

Returns the integer of the number of free bytes of memory the script can use.

Specification

This function's behavior is dependent upon the VM the script is using. Mono is the new VM, LSO is the old VM. The big difference between Mono and LSO is that Mono scripts run faster and can utilize four times more memory.

Mono

In Mono the value returned is the amount of free memory available to the script prior to garbage collection being run. This means that memory that is awaiting garbage collection counts against the scripts 64KiB allotment. In addition to this, Mono does not enforce the memory restrictions as strictly as the LSO VM did[1] (with LSO it was impossible to exceed the 16KiB memory cap), consequently it is possible to utilize more of the free memory.

LSO

In LSO, the value returned by this function is the amount of memory that the Stack can use of the Heap has yet to allocate for itself.

The LSL memory space is divided into four sections: Byte-code, Stack, Free Memory, Heap. Free Memory isn't an allocated block of memory, it's just the space between Stack and Heap. The size of all four sections combined is 16384 bytes (16KiB).

Strings, lists and keys are stored in the Heap. Heap pointers (for strings, lists & keys), integers, floats, vectors and rotations are all temporarily stored in the stack as the script executes.

As the script executes the Stack grows and shrinks in size depending upon the complexity of the expressions being executed. Likewise the Heap grows as the script executes but unlike the Stack, it never shrinks in size. When there is no free memory left for Stack or Heap to use they collide and a Stack-Heap Collision error is thrown causing the script to crash.

The Heap can become fragmented and blocks of memory in it can become unusable (due to their size). There is no defragment function[2] but there are scripting techniques that can be used to reduce fragmentation.

Caveats

  • The number of free bytes the Heap can use may be greater but not less.
  • "the number of free bytes of memory the script can use" means that if a memory limit is set (via llSetMemoryLimit), this function will report the free space between the script's current memory usage and the defined memory limit, not the uncapped memory limit.

Examples

Calling llGetFreeMemory can look like this:

llOwnerSay((string)llGetFreeMemory() + " bytes of free memory available for allocation.");

Notes

The amount of free memory is updated only at the start of a server frame, meaning the values from this function can fluctuate. To ensure stable values, use a single-frame sleep, e.g. llSleep(0.01) before the call to llGetFreeMemory.

See Also

Functions

•  llGetUsedMemory
•  llScriptProfiler A more advanced function for analyzing script performance, and can also measure memory usage over time.
•  llSetMemoryLimit Define a memory limit (lower than the maximum for the appropriate VM).

Articles

•  Stack-Heap Collision LSL Error caused by the script running out of memory.

Deep Notes

LSO VM Notes

This function does not count free memory, and the name of this function makes this function difficult for people to learn. People say this function may be redefined or superseded by another more useful function when the LSL VM moves to Mono.

We can concisely specify llGetFreeMemory in the context of the classic Unix model for a parallel task/ thread/ process. Think of the task of the script always holding 16384 bytes (16 KiB). Let the byte code and then stack grow up from the bottom, let the heap grow down from the top. llGetFreeMemory then returns the "historic lowest heap pointer minus the stack end pointer".

llGetFreeMemory does not count the bytes freed, llGetFreeMemory instead counts all the bytes never yet used.

Footnotes

  1. ^ http://www.langnetsymposium.com/2009/talks/17-JimPurbrick-SecondLife.html
  2. ^ Due to the design of the LSO VM, a defragment function is impossible.

Signature

function integer llGetFreeMemory();