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

Tom Duff td at pixar.com
Thu Jul 23 15:10:16 EDT 2009


On Thu, 23 Jul 2009, Hans Aberg wrote:

> 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?

Sorry, missed by one: the correct reference is one paper north on Wilson's
page: http://www.cs.utexas.edu/~oops/papers.html

Paul R. Wilson and Mark S. Johnstone.
Real-Time Non-Copying Garbage Collection.
Position paper for the 1993 ACM OOPSLA Workshop on Memory Management
and Garbage Collection, Washington D.C.
September 1993.

ftp://ftp.cs.utexas.edu/pub/garbage/GC93/wilson.ps

> 
> > 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.

I'm not sure why this is relevant or responsive.  All this demonstrates is
that if you use inappropriate methods, you may very well get
inappropriate results.

> 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 actually solves the  
> problems.

Again, I'm not sure why this is relevant.  Virtual memory is a relic of a
bygone era.  I don't recall having a paging-related performance problem in
music software in the last 15 years.  Even my laptop has 8GB of primary
storage.  Nothing ever gets paged out.

> 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).

What does this have to do with garbage collection?  The last time I
looked, a couple of months ago, Chuck's garbage collector was a stub, and
even the stub wasn't called from anywhere.  It doesn't have one!  Have you
used Supercollider?  Does it have the delay problems you're worried about?
Are they attributable to the garbage collector?

I don't know what you mean by "Simple IO" and in fact I don't believe that
delay inhibits real time melodic playing.  Tracker action pipe organs
typically have key-to-sound delays of 250 milliseconds or more.  For
centuries they have been the primary instruments of many of the foremost
improvisers in western music.

Unpredictable timing (delay jitter) is undoubtedly a musical problem, but
Wilson's incremental real-time garbage collector, as used in
Supercollider, is designed specifically to eliminate that.

-- 
Tom Duff.  The telephone was the death of Montparnasse.


More information about the chuck-users mailing list