Forcing garbage collection to reduce stack heap collisions #994
Replies: 1 comment
-
I'm seen this technique reported before, but haven't been able to get it to actually do anything. The timing of garbage collection is very obscure and though I've tried poking at it in various ways I've never really been able to pin it down. I have a suspicion that nothing will trigger garbage collection within a function, and that instead garbage collection is queued on function exit and run after a short delay. Thus:
...seems to consistently show no indication of memory being freed up. Likewise:
Doesn't seem to show memory being freed up reliably, but:
... seems to show that garbage has been collected. TL;DR, I haven't been able to find any evidence that the memory limit change technique actually works. I'd be happy to be proved wrong if you can get it to function on oc_dialog, but I suspect that we'll need a more significant refactoring to improve the spare headroom here. |
Beta Was this translation helpful? Give feedback.
-
It seems the Mono runtime is not very good at cleaning up unused blocks of memory leading to stack-heap collision, see for instance #993.
Adding a print out of free memory:
llOwnerSay((string)llGetFreeMemory() + " (oc_dialog) bytes of free memory.");
at the very end of the Dialog() function in oc_dialog will show how available memory is getting smaller when menu system is used.
It seems we can kick the memory garbage collection into action by jiggling the memory limit, same place at the end of Dialog function:
integer memlimit = llGetMemoryLimit(); // how much are we allowed? llSetMemoryLimit(memlimit-1); // reduce by 1 to force GC llSetMemoryLimit(memlimit); // set it back llOwnerSay((string)llGetFreeMemory() + " (oc_dialog) bytes of free memory.");
Does anyone have comments or opinions about using this technique ??
Beta Was this translation helpful? Give feedback.
All reactions