Adam Tindale wrote:

Hi Atte,

Can you attach the full program or programs. Please find the smallest example that borks in the same way so we can narrow down the bug.

Very tricky. It only happens on top of my home grown chuck setup, which consists of quite a few classes. But will try to narrow it down. I'd bet, though, it involves static member data/functions... -- peace, love & harmony Atte http://www.atte.dk | quartet: http://www.anagrammer.dk http://www.atte.dk/gps | compositions: http://www.atte.dk/compositions

Hi Atte!

I investigated, and it seems it was partly my fault. Attached are three files.

Thanks for tracking this down.

To reproduce a problem similar to what I had, run "chuck --loop instruments", then do "chuck + eats_cpu.ck". Because the call to Instruments.analog.bd() is not sporked (but called) chuck will eat cpu rapidly. Why is that? Is it my mistake or is this a bug in chuck?

This is a chuck bug (a chug) and it has to do with the incomplete garbage collection in the current release. We plan to fix precisely this type of problems and more in 1.2.0.6. In this case, the function analog_bd( ... ) instantiates and connects a patch

fun static void analog_bd(float dynamic, dur length) {

[snip]

sinosc s => ADSR env => dac;

[snip] Due to the bug, the UGen's are neither automatically disconnected nor garbage-collected (both should happen when the function exits). The former causes the gradual CPU overload, and the latter causes the memory explosion over time. To manually workaround the disconnect/CPU issue in 1.2.0.5, disconnect the patch before leaving the function: s =< env =< dac; To manually workaround the memory explosion, make the UGen's static members of the Instrument class (so they don't have to be recreated every time analog_bd is called). However, this runs into the other long-standing static member bug, which forces one to instantiate the object outside: public class Instrument { // declare static reference to sinosc // (due to 'static' not fully implemented for objects) static sinosc @ s; } // instantiate out here // (due to 'static' not fully implemented for objects) new sinosc @=> Instrument.s; Sorry for this horrid hack. We hope to resolve these chugs as soon as we can. Best, Ge!

Hi Atte!

...

This is a chuck bug (a chug) and it has to do with the incomplete garbage collection in the current release. We plan to fix precisely this type of problems and more in 1.2.0.6.

Not to be pushy, but would you have any ideas about ETA on this?

It's a good question. We hope to have it done by early August, but it's really hard to gauge how accurate that estimate is. We can only say with certainty that it's a top priority and at the front of the queue. Parts of it are already done, but quite a bit more needs to happen. Beyond that it's hard to foresee. Sorry there isn't a concrete answer to this, we certainly hope to get this done asap. Best, Ge!

...

Sorry there isn't a concrete answer to this, we certainly hope to get this done asap.

Maybe an announcement on the list accompanied by a rc snapshot?

Certainly - we will keep the list updated on the (mis)progress and may release an rc for beta-testing before putting out the release. Thanks!

I think I'll hold my breath, then...

Be careful. Stop if you see =>'s and syntax errors random floating about in midair... Best, Ge!

Ge Wang wrote:

To manually workaround the disconnect/CPU issue in 1.2.0.5, disconnect the patch before leaving the function:

s =< env =< dac;

Am I right that "env =< dac" would effectively stop the patch from calculating? So the extra disconnect is for the garbage collection to also grab s, right? -- peace, love & harmony Atte http://www.atte.dk | quartet: http://www.anagrammer.dk http://www.atte.dk/gps | compositions: http://www.atte.dk/compositions

...

...

To manually workaround the disconnect/CPU issue in 1.2.0.5, disconnect the patch before leaving the function:

s =< env =< dac;

Am I right that "env =< dac" would effectively stop the patch from calculating? So the extra disconnect is for the garbage collection to also grab s, right?

Garbage collection in ChucK is achieved with Control-C :) This is a future consideration. If you are doing long shows with ChucK it is good to shut it down and restart it a few times if you are loading in lots of UGens. In the 1.5 hour show I normally do I restart ChucK in 6 places to make sure it doesn't blow up.

ugenA =< ugenB would effectively disconnect ugenA and ugenB, and if neither is ultimately connected to dac (or blackhole), then they won't compute when audio is generated. Currently, however, they are not garbage collected. Garbage collection has recently been elevated from "future consideration" to "current consideration". Actually, much has long been considered and even implemented, though some crucial components still need work. We very much hope to have it working soon. In general, there are ways to structure a program such that it gets around the need for gc, but that's not the way it should be. We shall collect all garbage! Best, Ge!

Please, please, please use one of the sensible lisp-like garbage collection schemes rather than pure reference counting.

As with other parts of the implementation, we are open to experimentation. There is a multitude of gc algorithms to choose from (what fun). Our general approach is 1. make it work 2. make it right 3. make it fast (and robust for real-time) 4. make it small We plan to try a few approaches, including some flavor of reference counting (with cycle-detection) and eventually explore more advanced options such as incremental and generational gc. We may even provide a command line flag to choose the gc scheme (similar to recent Java hotspot vm's). Will keep our list updated and we may see a rc or two... Thanks! Princeton Waste Management Office