Script Mystery with llGetFreeMemory in Edited vs. New Scripts

[Love Zhaoying]

I've been recoding an existing script, using initial llGetFreeMemory() on state_entry() as a basic guideline for "how I'm doing" with the coding effort. Now, I realize that llGetFreeMemory() only gives you "Returns the integer of the number of free bytes of memory the script can use.".

Here is my mystery: as I got closer to finishing my conversion, the initial free memory was unusually low: 10k compared to the original script's 40k.

I tested (in a fresh script) initial memory used by each script for just globals, then functions, then state() code..and saw very little difference.

Finally, I copied ALL of the code from the "low memory" script to a fresh script - and initial free memory went from 10k to 52k. 

All scripts are compiled for Mono.

So now I have 2 identical scripts, one that reports 52k initial memory free, and one that reports 10k free.

Any ideas on the cause of this? Should I a) ignore llGetFreeMemory() completely, or b) copy all the code to a fresh script when I see this happening? I have a feeling I could reproduce this easily with some other scripts that I have been working on.

[arton Rotaru]

Weren't the llScriptProfiler, llGetSPMaxMemory, and llGetUsedMemory functions been introduced to return more reliable results than what llGetFreeMemory does?

[Love Zhaoying]

1 hour ago, arton Rotaru said:

Weren't the llScriptProfiler, llGetSPMaxMemory, and llGetUsedMemory functions been introduced to return more reliable results than what llGetFreeMemory does?

Good question. I was led to believe that llGetUsedMemory is no better than llGetFreeMemory. I can try the others also and see if results are more consistent. Does llGetSPMaxMemory include the code, or just memory allocated for variables?

 

[Nova Convair]

According to the wiki llGetFreeMemory does not return the free memory. It returns the free memory prior to the garbage collection. That means if you have unused and freed data on the heap llGetFreeMemory will not count that.

Quite a while ago I've read (don't know where anymore) that mono executes the garbage collection only if it's needed - that's when you exceed the 64k limit. It will execute the operation even if you exceed the 64k and will run a garbage collection after that.

llGetSPMaxMemory only makes sense if used with llScriptProfiler and will return the most memory used during or after profiling. You can use that to find out the how much memory a function uses for example.

A fresh compiled script has never used any memory so llGetFreeMemory will return the highest possible value for that script. A reset should have the same effect by my opinion but I never tested that.

 

Edited April 29, 2017 by Nova Convair

[Love Zhaoying]

23 minutes ago, Nova Convair said:

A fresh compiled script has never used any memory so llGetFreeMemory will return the highest possible value for that script. A reset should have the same effect by my opinion but I never tested that.

That is the mystery I am asking about. Both copies of the script are freshly compiled. Both report different llGetFreeMemory() at the initial state_entry().  Both are IDENTICAL scripts - I just copied the script text into a fresh script and I get radically different results.

As mentioned in my response to Anton, I will try script profiling and see if there is a difference. Unfortunately, the script in question is "in-progress" so I will have to finish and completely debug it in order to get the end-to-end behavior before profiling is meaningful compared to the script I am rewriing. Hopefully, even if I cannot see "how much memory is available" reliably, script profiling will give me the closest thing - how much memory I am using.  However, I suspect from the documentation that script profiling only gives the "allocated memory" (heap, stack) and not the memory used for the byte code itself.

[Love Zhaoying]

Unfortunately, my scripts have diverged too much now for profiling to be useful.  (I can try at a later date when I have two compatible revisions to compare.)

Can anyone at least answer whether "profiling" includes the memory used by the "code" size plus the allocated memory (for "variables")?  If so, it would be useful to me as then I can get an idea of the "code size" of my script.  I guess I could figure it out by creating two small scripts that allocate no memory for "variables" but instead just print constant text of various sizes..but that may still only show the size allocated for the text not the code to print it.

[Nova Convair]

Just do it the other way around and use llGetUsedMemory and your questions you can answer yourself by using a test script.

string test;

default
{
    state_entry()
    {
        llOwnerSay(llDumpList2String(["A",llGetUsedMemory(),llGetFreeMemory()],"\n"));
    }

    touch_start(integer total_number)
    {
        test = "djdjdjdhfgsdgsgsazezehehegegetetgdgdgdddddddddddddddddddddddddddddddddddddddddddddddd";
        llOwnerSay(llDumpList2String(["B",llGetUsedMemory(),llGetFreeMemory()],"\n"));
        test = "";
        llOwnerSay(llDumpList2String(["C",llGetUsedMemory(),llGetFreeMemory()],"\n"));
    }
}

As you can see - if you run it - llGetUsedMemory shows code+data

llGetFreeMemory shows the free data but does not take unused and freed memory into account.

There is no documentation about the compiler and the runtime environment of the scripts but it seems there is nothing too fancy. So I assume global variables go to the heap which will be fragmented over time. (Can be avoided by allocating data with a plan in mind)

Local data used in functions goes to the stack. And the stack pointer is reset to the old value when you leave a function. So all local data in functions is 100% freed once you leave a function. That does not help you if you need persistent data though.

 

[Love Zhaoying]

3 minutes ago, Nova Convair said:

As you can see - if you run it - llGetUsedMemory shows code+data

llGetFreeMemory shows the free data but does not take unused and freed memory into account.

Thanks! I wish the documentation was better.  I will give this a try in the "good" and "bad" versions of the script (the one that I got different answers for llGetFreeMemory() after putting code into a new script) and see if I get more consistent results than llGetFreeMemory()!