[chuck-users] GC vs real-time (was Getting Started with ChucK)
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
> Springer-Verlag, Berlin, 1992.
> 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
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
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