One of the way to characterise asap is as an inlined gc which is statically optimised. Specifically,
asap zealously runs gc-like cycles at every program point but only from a limited set of roots
and along a pruned set of paths. The set of roots and paths form zones which are chosen statically
based on information inferred by asap’s analyses. The zone specialisation is such that, at
some program points, the “inlined gc call” is removed altogether. However, this characterisation
is imprecise in three major ways. First, the timeliness of the two approaches differs: the
approximation of waste by Access is more precise than the characterisation by unreachability
of gcs. Second, the collection points are disjoint: in asap collections appear after each binding
and match1
instead of allocation points. Third, in asap, the scanning operations do not rely on
runtime type information (such as block size and pointerness).