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 -> 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