[gameprogrammer] Re: Scripting engines: Upvalues and function refs

[David Olofson <david@olofson.net>]

On Wednesday 14 April 2004 15.02, Julien Pauty wrote:
> David Olofson wrote:
> >>The GC is a  "mark and sweep" one.
> >
> >Ouch. A basic mark & sweep GC is a major showstopper in hard RT
> >systems. It has to be some form of incremental variant, so you can
> >control how many cycles it burns before you get back to executing
> >application code.
>
> Yes, it was quite a simple GC, only for soft RT. Usually if you
> loose a frame with soft RT it's not a problem. Of course with hard
> RT, this asumption fails.  I am not sure hard RT can live with
> garbage collection. Maybe with a very fine grain GC that you can
> precisely control (start and stop) and know its execution time.

There are basically two things to worry about, I think; running out of 
(instantly available) memory, and getting stuck in the GC so long 
that deadlines are missed.

Unfortunately, unless you have tons of memory to spare (which you 
often *have* these days, actually), you'll have to tune the GC to 
collect as quickly as possible without stealing too much CPU time.

One way is to just use all idle CPU time for GC, but that's not always 
easy or even possible to implement reliably. You can always poll some 
high resolution timer, call the VM scheduler or whatever at strategic 
places in the GC, but that's hardly optimal... Polling can be 
expensive, and it scales very poorly across CPUs with different 
speed.

Another way is to run the GC in another thread, but that strikes me as 
hairy and inherently non-portable, at least for RT use. Some 
platforms have issues with some sync constructs, they all have 
different APIs and quirks, and on some, the only way to get usable 
soft or firm RT performance is to do all RT stuff in single thread 
and use only lock-free communication. Other platforms don't even have 
threads, but run RT audio code in interrupt context. (Mac OS classic, 
DOS, Win16.)


[...]
> You could look in the wilson's survey on garbage collection  :
> http://www.cs.colorado.edu/~diwan/class-papers/gcsurvey.ps it's
> quite complete, but maybe you already know it :)

Yep, I've read that, and some other papers. :-)

I've even seen some stuff on RT GC, but it's not much... Most people 
assume that GC doesn't mix with RT and then just forget about it. 
Meanwhile, there are examples of RT systems that perform *better* 
with incremental GC than with refcounting or explicit memory 
management. Not too strange when you think about it. What you do is 
effectively throw all destruction and deallocation work out of the 
time critical code path.


//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---