[chuck-users] GC vs real-time (was Getting Started with ChucK)

Hans Aberg haberg at math.su.se
Thu Jul 23 14:16:46 EDT 2009

On 23 Jul 2009, at 18:54, Tom Duff wrote:

> On Wed, 22 Jul 2009, Hans Aberg wrote:
>> But if you you one which is tested and can guarantee no delays in the
>> programming threads, let's hear.
> Supercollider uses a real-time incremental garbage collector based on
> this paper:
>       Paul R. Wilson, Uniprocessor Garbage Collection Techniques,
>       Proceedings of the 1992 International Workshop on Memory  
> Management,
>       Springer-Verlag, Berlin, 1992.
>       ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps
> Wilson's method doesn't have to run in a separate thread (so no thread
> locking), the work done per allocation is strictly bounded (i.e. it's
> guaranteed that there are no long garbage-collection pauses during
> allocation), and the overhead per heap access is likewise constant  
> (and
> tiny.)

This is a survey article. Which method is used?

> There have been advances in the state of the art since 1992, but this
> method works fine for high-throughput systems like Supercollider,  
> and is
> certainly adequate for low-latency, low-performance systems like  
> ChucK.

The thread in comp.compilers on reference counting mentioned that the  
Java collector, when buffered grew beyond 50 MB or so, could choke and  
hang for tens seconds, even on the latest Macs.

Even if the GC works fine on a machine without virtual memory, it  
could choke in a virtual memory environment, if tracing takes place on  
swapped out memory. The whole system can choke. The before mentioned  
thread also gave some references, but none that actuaööy solves the  

And Chuck is in fact resource demanding because of its exact timing  
model. Simple IO in fact causes delays, enough to make real time  
medoic playing difficult (though I tried it in a not so fast computer).


More information about the chuck-users mailing list