the free memory
available, in bytes
, to the script
calling it. Free memory means 16kb
(the maximum each script gets) minus the size of the script's bytecode
, and heap
For Mono the script memory means 64 kb. (RC viewers) -Jor3l
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.
As of SL
1.10.6 (July 16, 2006), this function remains broken
! Confirmed 1.21.6 (Feb 17, 2009)
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