[chuck-users] Chuck garbage collection needs a manual
haberg-1 at telia.com
Tue Sep 7 07:55:47 EDT 2010
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.
More information about the chuck-users