1. Memory de-allocation question
- Posted by xecronix 3 weeks ago
- 214 views
Let's say I have a global sequence that contains 50K small sequences. Each of the 50K sequences is unique.
sequence s = make_crazy_sequence(50000)
I don't know exactly how much memory s takes up, but let's say it's enough to matter but not enough to be a significant problem on a modern PC.
What happens when I do this later?
s = {} -- does this free most of the memory? If so, instantly or eventually?
And a couple of follow-ups. Since s is a global, I might be incorrect in assuming there isn't a way to totally annihilate and free s. Am I? Do Phix and Euphoria behave differently?
Thanks.
2. Re: Memory de-allocation question
- Posted by jimcbrown (admin) 3 weeks ago
- 216 views
OE uses ref counts. So when you run 's = {}' that would cause those refs to hit zero. I'm not sure if it frees up right away, but I'm sure that it'd eventually get freed up since the refs get set to zero right away.
The other thing is that ref counts are decremented when variables go out of scope. So even if you didn't run 's = {}' if s is a variable that can go out of scope (e.g. it's in a routine) then it will get freed up eventually.
That doesn't apply to global variables, which never go out of scope and which you'd have to free up manually as above.
Note that this is refering to OE. I am not familiar with this part of the Phix inernals and don't know how it works there.
3. Re: Memory de-allocation question
- Posted by petelomax 3 weeks ago
- 207 views
Phix frees the memory immediately, and re-merges any adjacent blocks it encounters, all nice and efficiently.
If you're interested, have a quick skim of builtins\VM\pHeap.e - you'll learn a few things from the opening notes,
but I'll wager you'll give up when you get to the ~4000 lines of extremely hard-boiled inline assembly code...
As they say in the movies, any similarity to the behaviour of Euphoria code living or dead is entirely coincidental.
4. Re: Memory de-allocation question
- Posted by xecronix 3 weeks ago
- 196 views
Go to know. Knowing it frees, and in Phix immediately, simply by setting the variable to an empty sequence makes some performance tuning ideas a no brainer. Thanks.
but I'll wager you'll give up when you get to the ~4000 lines of extremely hard-boiled inline assembly code...
I have many shortcomings. Lack of tenacity isn't one. LOL But, to be honest, 4000 lines of assembly, probably FASM influenced, is not my next challenge.
5. Re: Memory de-allocation question
- Posted by petelomax 3 weeks ago
- 190 views
OOPS, I may have slightly mis-spoke. What I probably should have said is: "Phix immediately recycles and makes available for re-use by the same application".
As yet, Phix never actually returns any memory to the OS except at program termination, though I doubt that's really an issue, 'cept for what Task Manager shows.
Should it ever be needed, it is unlikely to be particularly tricky to add a new builtin, say free_memory() or release_memory(), that invokes HeapFree or libc/free.
If you were thinking about stalls, as I suspect you were, all Phix citizens send stuff to the recycle centre, instead of littering or putting bins out for the binman.
Technically and pedantically speaking that's probably not true under pwa/p2js, since in a browser JavaScript is simply going to do whatever JavaScript does.
6. Re: Memory de-allocation question
- Posted by xecronix 3 weeks ago
- 180 views
As yet, Phix never actually returns any memory to the OS except at program termination, though I doubt that's really an issue...
I think it does matter for my use case. BZScript currently builds several large intermediates before execution (file chars -> grouped tokens -> full AST). Once execution starts, those early structures are dead weight. By my rough estimate I could be holding up to ~30x the source size in transient data at peak, plus thousands of small short-lived chunks. Phix will reuse those, which is good, but the peak still sets a high-water mark in the process.
Takeaway: I need to rework the front end to stream and reuse buffers so only the final AST and symbols survive. Your note helped me catch this before it bites. Thanks.
7. Re: Memory de-allocation question
- Posted by petelomax 3 weeks ago
- 172 views
I doubt you have anything worth worrying about there: your source code is unlikely to reach 8MB, or the AST 250MB, which ain't gonna even slightly trouble any PC built in the last 15 years. But I'll be here if it does.
