[chuck-users] Chuck garbage collection needs a manual

[David Rush]

On 6 September 2010 23:55, Hans Aberg <haberg-1 at telia.com> 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).

david
-- 
GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20100907/13139c74/attachment.htm>