Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

llGetFreeMemory() under Mono?

Chaz Longstaff
Registered User
Join date: 11 Oct 2006
Posts: 685
09-11-2008 15:44
Wondered if anyone had any opinions yet about how reliable / unreliable llGetFreeMemory() is under mono [not that it was ever totally reliable pre-mono]. Reason I ask is that when adding a word, say, such as "apple" or "banana" (nothing longer) to a list , I'm seeing incredible memory drops (as reported by llGetFreeMemory()) between adds

[15:27] Animated Living Mattress 2.5: added 20 of 139 -- word "banana"
[15:27] Check Perms **-Longstaff MLP Checker: 18686 bytes free)
[15:27] Animated Living Mattress 2.5: added 21 of 139 -- word "orange"
[15:27] Check Perms **-Longstaff MLP Checker: 12234 bytes free)
[15:27] Animated Living Mattress 2.5: added 22 of 139-- word "apple"
[15:27] Check Perms **-Longstaff MLP Checker: 5206 bytes free)

Sometimes the script finishes its run to completion fine, other times it gives me, with last reported memory being "only" 4900k:

[15:16] Animated Living Mattress 2.5 [script:**-Longstaff MLP Checker]: Script run-time error
[15:16] Animated Living Mattress 2.5 [script:**-Longstaff MLP Checker]: Stack-Heap Collision


It just seems the reporting isn't accurate -- let me rephrase that -- way less accurate than before.

I mean, there's no WAY the word "orange" takes up 6,000 k of memory.

p.s. list adding being done using old hack of: list1 = (list1=[]) + list1 + ["apple"]
_____________________
Thread attempting to compile a list of which animations are freebies, and which are not:

http://forums.secondlife.com/showthread.php?t=265609
Pedro McMillan
SLOODLE Developer
Join date: 28 Jul 2007
Posts: 231
09-11-2008 16:37
If the function works as it did before (i.e. only reports the minimum amount of free memory so far), then perhaps stack usage will be detracting from the perceived memory availability. I would hazard a guess that Mono has a much more demanding stack, given that it's not domain-specific (unlike pre-Mono LSL), and also given the quantity of extensions and so forth.

Could be wrong though... might just be another glitch to add to the list!

EDIT: it also occurs to me, under Mono, that lists might be implemented as a tight heap-array... i.e. when you add something, it actually has to create a new array of the new size, in a new location in the heap, and copy all the existing stuff across before adding your new item.
Very Keynes
LSL is a Virus
Join date: 6 May 2006
Posts: 484
09-11-2008 16:56
From: Pedro McMillan
EDIT: it also occurs to me, under Mono, that lists might be implemented as a tight heap-array... i.e. when you add something, it actually has to create a new array of the new size, in a new location in the heap, and copy all the existing stuff across before adding your new item.

Ouch, I hope not or that kills the project that I have had on hold waiting for mono. But I too am seeing the same issues as Chaz, and wondered if it was the list1 = (list1=[]) + list1 + ["apple"]
I have been waiting for things to stabilise on the grid before testing, but I think its time I took my beta mono code and tried it in the main grid, my poor neighbours will suffer if my calculations are wrong.
Pedro McMillan
SLOODLE Developer
Join date: 28 Jul 2007
Posts: 231
09-12-2008 00:13
I'm just making wild stabs in the dark to be honest. That particular method is how so-called "dynamic arrays" would be implemented in a language like C++ (although most of them would have some leeway... e.g. a few 'spare' elements so you can increase it to some degree without slowing things down).

Bear in mind, this approach was a very context-specific 'optimisation' for pre-Mono LSL:

list1 = (list1=[]) + list1 + ["apple"];


In most languages, the following *should* be vastly more optimal (so I recommend trying it instead):

list1 += ["apple"];


Assuming my theory about a tight heap-array is correct, then here's what the LSL-optimisation above might cause under Mono, if there are no significant compiler optimisations implemented yet:

* original list1 temporarily still exists for copying
* new empty list created by ";(list1=[])"
* a new temporary copy of list1 created by the combination of [] and list1 (the first +)
* a new list created to store ["apple"]
* a new temporary list created by second
* final temporary list copied to new location in memory
* address of final list stored back in original list1

That could give us as much as 6 different lists in memory all at once. Assuming I've read your debug info correctly, and the list contained 19 items by the time "banana" was added, and assuming an average element size of maybe 8 to 10 bytes, then old LSL memory usages would require between 700 and 800 bytes to do that operation. Why it would take up 6000 bytes under Mono is a mystery... but hey... hopefully LL will sort it out!

(I could be waffling total nonsense here... more or less thinking out loud!)