Kas (and ChucK community): The code I'm writing really needs a "wait-on-event-or-timeout- whichever-comes-first" function, and the obvious way to write this is to spork a shred at each call. Since I will be using ChucK in live performances, the fact that memory is exhausted after 20K calls to woeotwcf is a concern to me. If shreds are allocated from a pool, then profligate sporking isn't what's causing the system to run out of memory, but without monitoring tools, I have no way to know. The short statement is "I can't optimize what I can't see". It would be nice to have visibility into where the storage is getting eaten up. Or a GC. - Rob On 17 Mar 2009, at 20:08, Kassen wrote:
Rob;
Are there tools or techniques for monitoring memory allocation in ChucK? I've been stress testing my code, and after about five hours ChucK vm stops with a malloc / mmap failure. It would be nice to figure out what's clogging memory. [In a previous life, I was an embedded systems programmer, so I'm happy to create reusable object pools and managing the objects myself, but I need to know what leaks and what doesn't.]
From my experience (looking at task manager on Windows and Top on Linux) defining anything will allocate memory and this won't ever be freed. I'm not sure what the current state of garbage collection is but last time I checked I believe this even included the temporary variables in "for" loops. In case of doubt it's currently fairly safe to assume it'll leak though memory allocated for samples should be freed (I think).
For some types of program you can simply make sure to never define anything inside of loops, going as far as to re-use the temporary variables in those "for" loops. I think that can lead to garbage- less code but I'm not sure about function calls.
That's the bad news (I think everybody agrees this is quite bad).
the good news is that it's being worked on and some GC is (supposedly) already in place.
One of the most important techniques I use to deal with this is making sure anything "large" (classes, UGens) of which I need multiple copies will be stored in a array so I can re-use one copy once I'm done with it; basically I try to make sure it never becomes impossible to address. This creates some overhead in code and complexity but at least memory leakage will be contained to reasonable levels.
Hope that clarifies, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users