From: Leandro Lucarella <llucax@gmail.com>
Date: Thu, 9 Sep 2010 03:17:16 +0000 (-0300)
Subject: Add eager allocation support when fork()ing
X-Git-Url: https://git.llucax.com/software/dgc/cdgc.git/commitdiff_plain/6a40cbf5959226bf1e6ec7bdb6c7e03253072c28?ds=sidebyside;hp=6a40cbf5959226bf1e6ec7bdb6c7e03253072c28

Add eager allocation support when fork()ing

Eager allocation consist in allocating a new pool when a collection is
triggered (because an allocation failed to find enough free space in the
current pools). This enables the mutator to keep running when the mark
phase run in a fork()ed process in parallel. This completes the concurrent
GC, decreasing the maximum pause time (not only the stop-the-world time)
dramatically (almost by 2 orders of magnitude).

As a side effect, the total run-time is greatly reduced too because the GC
pressure is reduced due to the extra allocated pools. The number of
collections needed by a program can be reduced 3 to 9 times depending on
the load, which explains the total run-time reduction, even for
single-core environments.

To allow the mutator run in parallel with the mark phase, the freebits
of free pages must be set for *all* the possible block sizes, not only for
the start of the page, because the freebits are used as a starting point
for mark bits and the bin size of a freed page can be changed *after* the
mark phase is started, resulting in an inconsistency between mark bits and
free bits. Pools allocated during a parallel mark set all the mark bits
to avoid the sweep phase freeing those pages after the mark is done.
---