[chuck-users] Chuck garbage collection needs a manual

[Hans Aberg]

On 7 Sep 2010, at 10:43, David Rush wrote:

>> GC ought to be wholly independent of the ChucK thread that syncs  
>> the music, since it is only about collecting unused memory. Suppose  
>> you have a collecting GC that runs nicely in the sense that it does  
>> not interrupt ChucK perfect timing. Then it could within that  
>> limitation collect whenever it gets some time from the system to do  
>> it in its own thread.
>
> Both real-time and multi-threaded GC are still considered *hard*  
> issues in the PL community. In a multi-threaded app, you have to  
> address how to keep the mutator alive and kicking during the GC  
> cycle (since the allocation graph is clearly a shared data  
> structure), and in a  real-time app, you have to address the problem  
> of deadlines even though the mutator may cause very uneven GC loads.
>
> It does turn out that both problems are loosely related, but it's  
> not at all easy to adress the issues in any given application.  
> ChucK's reference-counted approach is one that is works quite well  
> in real-time systems, but reference-counting has the downside that  
> it can be very buggy if it is implemented manually, and it is quite  
> easy to cause naive reference counting to leak (so you still have to  
> be acutely aware of the object life-cycle).

ChucK, because of its strong timing, runs in a single thread. So the  
question is if one might put something in another thread. A concurrent  
GC would qualify, at least from the theoretical point of view.