[chuck-users] Getting Started with ChucK

[Hans Aberg]

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