Mon Aug 17 10:27:47 CEST 2009

Does PF need real-time GC?

Note that I realize that these days it is possible to get real-time
incremental GC.  However, these are still not synchronous memory
managers: they won't reclaim large blocks immediately so always
require more memory than a synchronous GC, and on top of that will
cause unnecessary loss of data locality.

This doesn't mean that the current (very simple stop-and-copy Cheney
GC) can't be replaced by something more elaborate to make the
_compilation_ also respect real-time constraints.

Otoh, since the linear and graph memory are completely separate, and
the GC will never modify the linear data, a GC that doesn't move the
data can be run in a low priority thread without problems.

So, yes: I guess I'm taking position _against_ real-time GC, at least
for scripted DSP applications (for static compilation, you can
probably use static buffer allocation) where large chunks of memory
are allocated and freed at a rapid rate.  It seems that the
multitasking approach makes more sense: a linear core which can use
(read-only) data and code from a nonlinear one.

... Baker 1978[1] -> contains some information about CDR coding.
Useful for making byte code sequential (cache-friendly).  Chapter 8 is
of interest though: talks about RC counting.

The trouble with RC managed data that Baker mentions is that a `drop'
of a huge data structure takes a long time to deallocate.  He suggests
to do te deallocation lazily.  In practice though (especially due to
the `physical' nature of linear objects) this doesn't really happen
much.  Consumption rate is usually one-by-one.  And, lazy dealloc
still doesn't perform fast reclaim for cache locality, what we're
really after..

[1] http://home.pipeline.com/~hbaker1/RealTimeGC.html