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