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.