Don't click here unless you want to be banned.

LSL Wiki : llGetFreeMemory

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are
integer llGetFreeMemory()

Returns 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, 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
There are 3 comments on this page. [Display comments/form]