[<<][libprim][>>][..]
Tue Aug 25 08:34:16 CEST 2009

Real-time GC

PF uses linear core memory management and nonlinear code memory
management.

With linear memory management I mean that the machine's run-time uses
_only_ a tree data structure.  SEQ encodes all the rest, and is the
basic data structure of the nonlinear memory.  (Essentially, SEQ is
only constructed at compile time: during run-time the code structure
is constant.)

The reason for this is that (in my understanding), "real" real-time 
tracing garbage collection doesn't exist.  It exists for memory-only GC, 
but in practice you also want to manage much more scarce hardware
resources which in the light of a real-time GC _still_ require full
non-bounded collection steps.

If you replace a tracing GC with refcount management system, then you
can have real-time GC, given that you realize GC cost is proportional
to the _size_ of data structures you destroy.  In practice, this isn't
a problem.  An embedded system usually has a loop with very
predictable data usage.  The case where you destroy a single data
structure containing a large amount of objects is rare.



[Reply][About]
[<<][libprim][>>][..]