Architecture of Computing Systems (Lecture Notes in Computer ...

An Embedded GC Module with Support for Multiple Mutators 31
3.3 Exact Garbage Collection
Targetting the employment in constraint embedded devices, it is essential to provide
an exact GC. A conservative collection is simply no option as its impreciseness
would have to be paid for with additional usually spare memory resources.
The exact garbage collection must be capable of a clear distinction between
references and primitive data. This may be achieved either by the direct tagging
of data words or by administrative metadata. The latter option is the more
economical on the heap where only instances of well-defined class layouts reside.
Adopting the bidirectional class layout of the SableVM [18] further allows to
reduce the required metadata to the sizes of the primitive storage growing with
positive offsets and of the reference storage growing with negative offsets from
the object’s base address.
Our GC architecture features distributed tapping modules to collect the root
set of references from the mutators. These must also be able to identify references
precisely within the tapped storage elements. In our adaptation for SHAP,
we chose the tagging approach for the internal stack and registers as the data
contained therein does not follow a only handful of structural blueprints.
3.4 Object Graph Marking
Our architecture builds upon a decentralized collection of the root set. Each
mutator core is extended by its own root scan unit, which collects the references
contained in the local registers and stack into a mark table. As shown in Fig. 1,
all mutator cores are arranged in a ring on a GC bus, which is mastered by the
MMU. This unit issues commands onto the ring and receives their acknowledgements
as they return on the other end. This ring also serves the gradual merger
of the contents of the individual root tables into the global root set. While the
MMU transmits an empty table, each core ORs the received table with its own
table contents before forwarding it along the ring. The final result is entered into
the central mark table inside the MMU.
The local root scans operate concurrently to their associated mutator core.
Once finished, they are deactivated for the remainder of the GC cycle so that further
modifications of the local root sets are not logged. This is safe as the mutators
only gain access to other references by loading them from objects – which were,
thus, reachable from the original root set – or by creating new ones. Objects allocated
during the GC cycle are already implicitly marked by the allocation engine.
After the completion of all root scans, the actual computation of the reachable
subgraph is performed by the heap scan. Our optimized variant of the wellestablished
tri-color marking uses the mark table to tell reached from unreached
objects. The colors red and green further distinguish the reachable objects into
scanned and unscanned ones. The meaning of these colors alternates and is determined
by the color of the active GC cycle. Initially, all references are unscanned
and have the color opposite to the current cycle. Upon being scanned, a reference
assumes the cycle color. References to newly-allocated objects are immediately
assigned the active color as they do not contain valid references and need not be