Note [Sync phase marking budget]

The non-moving collector is intended to provide reliably low collection
latencies. These latencies are primarily due to two sources:

 a. the preparatory moving collection at the beginning of the major GC cycle
 b. the post-mark synchronization pause at the end

While the cost of (a) is inherently bounded by the young generation size,
(b) can in principle be unbounded since the mutator may hide large swathes
of heap from the collector's concurrent mark phase via mutation. These will
only become visible to the collector during the post-mark synchronization
phase.

Since we don't want to do unbounded marking work in the pause, we impose a
limit (specifically, sync_phase_marking_budget) on the amount of work
(namely, the number of marked closures) that we can do during the pause. If
we deplete our marking budget during the pause then we allow the mutators to
resume and return to concurrent marking (keeping the update remembered set
write barrier enabled). After we have finished marking we will again
attempt the post-mark synchronization.

The choice of sync_phase_marking_budget was made empirically. On 2022
hardware and a "typical" test program we tend to mark ~10^7 closures per
second. Consequently, a sync_phase_marking_budget of 10^5 should produce
~10 ms pauses, which seems like a reasonable tradeoff.

TODO: Perhaps sync_phase_marking_budget should be controllable via a
command-line argument?