llGetFreeMemory

As the forum search doesn't give any results for this search term, I assume there's no entry for it... (although I kinda doubt that, but I'll ask my question anyway)...

In the Wiki (@www.lslwiki.net) it is said, that every SCRIPT gets 16kb of memory - I actually always assumed I'll get 16k per PRIM...?
So having multiple Scripts in one prim would actually «boost» the available memory? I thought, I'd have to rez multiple prims to achieve that and then let the prims (in a linkset) «talk» to each other...

And - it is also stated in the wiki that the function is broken:



So it seems calling this function after a certain runtime would be pretty useless. If I had Lists filled and emptied, the function wouldn't return to correct amount of memory available?

llGetFreeMemory lies. The memory may be available but it won't tell you. Dispite it's lies, your script will still use the memory.

Memory in LSL doesn't leak, it just becomes fragmented.

THat's right. 16 KB PER SCRIPT.

Not really broken, It is just the way it is implemented.

Correct again BUT......... It still comes in quite handy. You can put a limit into your script so that if the free memory == 3KB (pseudo code) it will stop accepting data or dump parts of the list etc. So it doesn't really matter if the memory is freed up, when it starts to fill again, it will still do whatever when you reach your pre-set limit again.

Thanks for the help folks...

But Jesse - When I can't rely on the llGetFreeMemory-Function, how can I compare a defined memory limit to the actually free memory of the script? Or do I get this completely wrong now?

It's 16k per SCRIPT not per prim. So you could have 10 scripts in a prim to have a total memmory of 160k if you knew how to have each script communicate.

As stated on the lslwiki, this function is broken and will ALWAYS be. It recalls the lowest memmory it ever has, not memmory in real time.

The reason its "broken" is because it would have to collect garbage every time anything in the script is called and that would require too much proccessing time.

I read the title as llGetFreeMoney(), here I was hoping a new function had been added...

I have heard that it's fragmented, not leaking, as Strife stated, but doesn anyone have any tips for how to reduce or eliminate this fragmenting?

So - as I understand, there's no way to get the actual runtime free-memory... well - gotta find another way then

@Darien - THAT would be a nice feature... ))

Nope you were right. I was confused for a minute. I have used it before for an upper limit, but only when I could afford to have it trigger llResetScript(). aka Clear all lists. Reseting the script will clear the high water mark. I also used it in a PrimMem setup so that when the memory filled it would pass the data(visitor list, names/keys) on to another waiting script and then it would reset and start again.

and as it stands, Jesse's implementation is about the only use I can see for it outside of some testing roles... why they set it up as a high tide marker, rather than a current snapshot, who knows... possibly because of the way memory is written in the script, so it always knows that last available space to write to (which would explain the fragmentation as it (re)fills memory up to that point) and was thus easier to access/write/implement

Thanks again guys...

A little further into the topic (why I actually came up with FreeMem). I have some lists, that I don't know how big they will grow. I wanna make sure, though, that no data is lost and the user can add as many entries to the system as he/she wants to.

I was thinking about having more scripts in my object just to store lists to them. But since I can't «create» a new script on the fly (as I can't write to a notecard *sic!*), I'd have to create like let's say 20 extra scripts, but even then, they'd fill up the sooner or later (depending on the amount of data which will be stored).

So I was thinking about rezzing new linked objects when the storing script is full, each of the new object containing more scripts to store data... I'm not quite sure though, whether this is a good idea, since those extra prims would count against the Land-Owners Prim limit and thus this process could also fail und certain circumstances...

Actually, it might well be that I don't even need this much of storing space - I'm just thinking about the concept of storing unknown amounts of data...

What's your approach to this?

use external data storage and retrieval methods.

sql/php or other solution.

just a small heads up, depending on how much overhead each script has, you can store between 150-300 keys safely as individual list elements, per script (the range is based on how you implement the adding to the list)

myList += (list)newKey; //-- will store ~150
myList = (mylist=[]) + myList + (list)newKey; //-- will store ~300

the limits are actually higher, I've pushed about 160/320 into a low overhead script before collision... not sure what effect fragmentation will have on that.

a thought for auto extensible storage scripts would be to give a copy of an existing script to the prim it's in... not sure if that would work, but it's worth a try.... for science.

logic would be, storage script continues to add items to it's list untill it hits a preset limit, then it switches modes to read only, and gives a copy of itself, which will accept writes.

Void...

That sounds like a nice idea to extend the storage capacity... I'm gonna try it (and report if it works, if I can remember it then

Thanks for the thoughts!

The real problem you run into with memory limits and lists is modifications. The 'mylist = (mylist = []) + mylist + ["blah"];' trick works to allow for adds (inserts), but edits and deletions will fail spectacularly, because the functions that manipulate lists make multiple temporary copies, which you can't really do when memory is beyond half full.

So, you can get "database" scripts to store that many entries, but it only works for inserts and clears. Update/Delete don't appear to be possible for large lists.

Right, not for large lists. So you set your upper limit down below the limit where you encounter a stack heap collision. What I usually do is once i get the script how I want I then tweak it to where everytime I touch it, it will copy a string of a fixed size into the list twice, then delete one copy, then read out available memory. Just keep touching the script until you hit the stack and you will have in chat history the last good memory size and set the limit below that.

Just depends on the data you need to store and how important the data is. I used a trick like this to know how many entrys I could add into my teleport hud safely and put a cap into the script. That ones stores destination name, sim name, vector in a strided list and works fine. Although I have never had the script reset in a year and a half, I know that the data is vulnerable. But for what I am doing it is now problem, it is easy enough to bookmarks the destinations again.

Same thing if you just want to make a log of people that visit your store for example. If the info is critical to you, then store it off world but if not, guesstimate how many names could possibly go into the list before you would retreive it and set the number of scripts accordingly. If you want to keep track of who is buying a product of yours and you have to keep a record in case of returns or upgrades.......... Then either email the names to yourself or send them out of world to an external server.

Well, how about collecting garbage each time the llGetFreeMemory() function is called?

Frankly, there's no good excuse for this function being as stupid as it is. Just lame ones. We only have 16K memory, so the overhead wouldn't be too significant, and LL could impose a 1 second delay to avoid CPU hogging with it.

I wonder whether any existing code would be adversely affected by fixing this function. I rather doubt it.

I agree. They could even track allocations/frees when they are done with VERY minimal overhead. It is what I ended up doing with my database scripts anyway.

I think the original function was designed more on a lark "hey, I can subtract TOS and BOH values and come up with a free memory function!".

That is how it is calculated, the problem is the heap can only grow in size, bug it can't shrink (the stack grows and shrinks).

I've have toyed with the idea of implementing a defragmenter but it isn't something that I really want to volunteer my time for... I expect it would require overhauling the heap code.

A few months ago I realised a way of getting 100k+ storage for a single script... by storing data in the event queue!

Have it send link_messages to itself. Every link message can hold a string, which can be as long as you can fit in memory.... but you can buffer 64 of them on the event queue.

You can put the script in a separate prim, and have the script stall with a loop (eg, an empty while loop, which waits for the colour of a prim face to be changed - or a while loop with a sleep (is that less laggy?)). Since it's stalled, the event queue will remain static. When you need a data operation, change the prim color to break the loop, and then the data holding script runs along the lines of: "Get a link message. Has this message got the data I need? No? Resend it to myself (to the back of the queue). Yes? Do the data operation, resend the message, then go back into the empty while loop."

I didn't complete it because I was worried about the effect on sim ecology, but maybe someone here knows what that effect would be, better than I did..

That's a clever idea. But yes, I would wonder the sim effects. I may have to play around with that.

That "memmory" saver technique has been on the wiki for over a year now.

It's a rather interesting idea and I've tried it but its quite a pain. You can store 64, but I'm not sure how long that queue lasts. Also in order to retrieve them one by one, you'd need to constantly change states in order to prevent it from recieving all 64 at once.

change states? nah just do all your actions inside the link_message handler, basically:

link_message( declarations )
if (message == what we want)
{
send message elswhere
reset color
empty do loop while testing color
}
resend message to self

it's the comparison part that's hard, because you'd have to cycle through all the messages before getting to your command, THEN start testing, unless you use some other prim property to grab your comparison item (like description?) or specify your needed index

If you do this, you will want to not pack the event queue. You wouldn't want another script sending a LM during a parse and having it get trapped in the queue and have the queue bounce one of your DB LMs.

This will cause sim crossings to go slower.