[chuck-users] recycling program

Robert Poor rdpoor at gmail.com
Wed Mar 18 01:53:44 EDT 2009

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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

More information about the chuck-users mailing list