On 22 Jul 2009, at 00:06, Tom Lieber wrote:
But there is a problems with the GC. The Wikipedia page did not specify. Pretty much the only GC that can fulfill the requirements of exact timing without jumps and concurrency is reference counting.
How slow is garbage collection? No ChucK code executes with exact timing even now. It's on the user to spread out computation to avoid delays, just as it would be on them to mind their allocations to avoid GC delays.
Concurrent GC would be nice, but making the VM multi-threaded is not the only way to synthesize sounds faster.
There is a thread in the Usenet newsgroup comp.compilers about reference counting that discusses some of these things. The moderator got bored with all these GC discussions - so one aspect of it is that one may end up implementing GCs rather than a programming language! :-) The problem is not getting the GC fast enough, but they tend to do collecting at a specific time, when the whole program sort of halts. This would easily exceed the few tens of a second that would be acceptable in a live performance with Chuck - even that would unacceptable. One might try to avoid that by having GC run in a separate thread, but there are problems with that, too (don't remember exactly). One interesting thing that came up was that a tracing GC may need to trace swapped out virtual memory, which when swapped back into memory causes delays - the hard drive is a bottleneck.
I'm more interested in bringing ChucK ideas to other languages than the other way around right now. Other VMs have had a few more eyes and hands on them, and adding timing rules to them has been easier than adding language features to ChucK for me. I'm leaving that to the pros!
The problem is that these other GCs probably are not designed for real time issues, but to speed up programming. One needs something that can be used in real time systems. Hans