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.