integer llGetFreeMemory()
Returns the free
memory available, in
bytes, to the
script calling it. Free memory means 16
kb (the maximum each script gets) minus the size of the script's
bytecode,
stack, and
heap.
For Mono the script memory means 64 kb. (RC viewers) -Jor3l
NOTE: The above statement I have found to be untrue & should be ammended to exactly as LL has it stated in the client: "returns the available heap space for the current script".
SiRiSAsturias
after studying the released sourcecode and testing with llGetFreeMemory() I have found out, that the function description is correct, it actually returns the bytes between the top of the heap and the stack pointer, this function does not return historic free memory as described in the text below this notice. The explanation why this function seems to not return freed memory is, that the heap itself is only grown, never shrunk by the VM. This can be checked inside the viewer sourcecode available from LL in the file linden/indra/lscript/lscript_alloc.cpp. In my tests that I did after understanding the source I had calls to llGetFreeMemory() returning lower and higher values. -
ThomasShikami
As of
SL 1.10.6 (July 16, 2006), this function remains
broken! Confirmed 1.21.6 (Feb 17, 2009)
llGetFreeMemory will
not take into account memory that has been freed, which can result in far less free memory reported than actually exists. What it
will report is the
historic free memory--the smallest free memory up until that point. So, in theory, your script could have nearly 16kb free, but report only several
bytes free. Depending on what you need, this isn't necessarily a bad thing, but if you're relying upon
llGetFreeMemory to know when a script is "full", you may run into some problems.
The historic free memory problem could potentially cause a situation where your script has several kilobytes of memory free, but "thinks" it only has a few bytes available. Other than to suggest that you attempt to design your script in such a way that this can't happen, there isn't a workaround for this situation.
The fluctuations in the value reported in scripts running in Mono is explained in the video recorded at Lang.NET (
blog entry video around ~65th minute). It is designed this way to limit the Garbage Collector cycles. As Jim explains, with thousands of scripts running on a sim calling Garbage Collector for every script every time some memory is freed would cause huge overhead and would cause additional lag.
Q: Does llResetScript also reset the historic low memory mark?
A: Yes. It calls the Garbage Collector to free the memory.
This article wasn't helpful for you? Maybe the
related article at the LSL Portal
Functions |
Memory