Adapt conservative default to the compiler support When compiling the GC with a compiler that doesn't provide PointerMap information, the conservative option defaults to true, as most likely the GC will be used with programs compiled with the same compiler and all data will be scanned conservatively anyway.
Add (optional) early collection support When early collection is enabled, the collection will be triggered before the memory is actually exhausted (the min_free option is used to determine how early the collection should be triggered). This could remove a little pressure from the GC when eager allocation is not available (or when eager allocation makes the heap grow too much). The option is disabled by default and can be disabled with the early_collect option.
Accommodate the heap size to the working set size The GC can have a lot of pressure if a collection recovers very little memory, but enough to fulfill the current memory request, causing a lot of collections with too little gain (when the key to a efficient GC is recover the bigger amount of memory with as little work as possible). This effect is greatly reduced when using eager allocation, because eventually the GC will allocate more memory, but heap minimization can trigger this effect again. This patch adds an option, min_free, which specifies the minimum percentage of heap that should be free after a collection. If the free heap is less than min_free% of the total heap, the GC will allocate a new pool, big enough to fulfill that requirement. If the free heap is bigger than min_free% of the total heap, the GC will try to release some pools to the OS to keep the heap occupancy near min_free%.
Try to keep the memory usage low more aggressively Memory usage is minimize()d only when a big allocation is done. This could be problematic for applications that only perform small objects allocation, as their memory usage could grow a lot, specially if the eager allocation option is used. Trigger memory minimization even for small objects allocation to avoid that pathological case.
Add pre_alloc configuration option The new option is used to pre-allocate pools of memory at program start. This could be useful if your program need to load a starting working set into memory before doing the actual work, as it might avoid some useless initial collections while the program is just doing allocation but no memory is yet freed. The option takes a numeric parameter indicating the size of the initial pool in MiB. It can optionally specify an arbitrary number of pools to create by appending "x" and the numeric value of the number of pools. Each pool will have the specified pool size. For exmaple, pre_alloc=50 will allocate an initial pool of 50 MiB, while pre_alloc=5x10 will allocate 10 pools with 5 MiB each. Anything that can't be parsed correctly (like "", "5x", "5a10", "5x10x", etc.) make the starts with no pre-allocated memory as usual.
Don't segfault if stats files can't be created If any stats files (used by collect_stats_file and malloc_stats_file) can't be created, the program segfauls trying to use a null FILE*. It's extremely impolite to cause an strange segfault because of this, and since there is no sensible error reporting mechanism either, we just ignore those options if the selected files are not writable, as we do with unknown options or any other wrong option parameters.
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.
Build the freebits bit set incrementally As a side effect, we can't copy anymore the freebits as the starting mark bits because we don't keep the freebits updated so precisely, doing so would need a bit more work. Since the freebits can be constructed in the mark phase, which we can do in parallel, this might not be as useful as thought at first.
Avoid redundant checks for finals bits In changeset b28fd72842fc9ce935bed74f7b2ba79f9cc59711 (Run the mark phase in a fork()ed process) we inadvertently changed the lazy allocation of finals bit set to eager allocation. This change left a lot of finals bit set initialization checks that are not really needed using eager allocation. We remove this redundant check as we decided to go with the eager allocation to trade some space for a little more speed, as the extra checks takes time and is very rare that a whole pool doesn't have any blocks that need finalization, making the space saving very rare too. Lazy allocation can impact too in locality of reference, as is more likely that all the bit sets are allocated near in space, except for the lazyly allocated one.