Best practice on parallel + incremental / generational ? about bdwgc

[plajjan]

I suppose one thing I'm interested in understanding is what sort of overhead one can expect from the incremental collector and its various VDB options?

Using parallel mark I get a significant performance improvement, like a test program goes from close to 13 minutes to running in less than 4. However, if I instead enable incremental collection I end up at around 10 minutes, i.e. ~3 minutes better. Using incremental + parallel (with GC_TIME_LIMIT=GC_TIME_UNLIMITED) I end up around 11 minutes, so worse than just the incremental and a lot worse than just parallel. I was really hoping that detecting dirty pages and only scanning them would be a lot more efficient than scanning whole heap. Am I doing something wrong? What are the general expectations when it comes to parallel + incremental? Is it supposed to be fast? :) Am I tuning it wrong?

[ivmai]

I haven't seen any benchmarking of parallel mark + incremental/generational yet.

Probably Unity folks did benchmarking (https://blog.unity.com/technology/feature-preview-incremental-garbage-collection, e.g. @jechter).

/cc @hboehm

[ivmai]

Parallel marking disabled due to stop_func != GC_never_stop_func
I don't understand the logic around stop_func. What happens that disables the parallel marker?

True incremental mode (when a collection is interrupted after a delay) with multiple markers is not implemented yet. It requires a change in GC_do_local_mark and related functions. Might be not difficult to implement, but I haven't estimated it. See issue #151.

[ivmai]

I haven't seen any benchmarking of parallel mark + incremental/generational yet.

And nobody tried to optimize it I suppose.

[ivmai]

various VDB options

On Linux/x64 there are only 2 variants of automatic incremental mode - SOFT_VDB (using /proc/self/pagemap, implemented in #265) and MPROTECT_VDB (using mprotect and fault handler). The first one is the default one (provided the kernel supports it). The 2nd one could be selected either but compiling with -D NO_SOFT_VDB or at runtime by setting env GC_USE_GETWRITEWATCH=0.

[ivmai]

Using parallel mark I get a significant performance improvement, like a test program goes from close to 13 minutes to running in less than 4.

It's a bit out of topic, but did you benchmark it with different number of markers? The current strategy is to have same number of markers as the number of cores available (but not more than 16).

[plajjan]

@ivmai let's say I don't care about interrupting a collection after some delay. I can run a "complete collection" but I want it to run through only the dirty pages instead of the whole heap. And I want to run through with parallel markers. Shouldn't this be possible today? That's what I understood -DPARALLEL_MARK + incremental mode with GC_TIME_LIMIT=GC_TIME_UNLIMTED should do? Maybe it does, but it is much slower than plain PARALLEL_MARK. Is this expected?

[ivmai]

I can run a "complete collection" but I want it to run through only the dirty pages instead of the whole heap.

No, this works differently (as explained in gcdescr.md): the collector may run for a small amount of time not stopping other threads, periodically, and later performs stop-the-world collection of dirty pages only (thus each collection is shorter but totally the collection work takes longer time because the collector needs to rescan dirty pages). Thus, according to your description what you need, the incremental/generation mode is not beneficial for you.