Rob;<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.]<br>
</blockquote><div><br>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).<br>
<br>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.<br>
<br>That's the bad news (I think everybody agrees this is quite bad).<br><br>the good news is that it's being worked on and some GC is (supposedly) already in place.<br><br>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.<br>
</div></div><br>Hope that clarifies,<br>Kas.<br>