On 30.10.2014 04:02, Martin Nowak wrote:
On Wednesday, 8 October 2014 at 18:25:00 UTC, Rainer Schuetze wrote:
I'm benchmarking my Windows version of a concurrent GC with it. It
does quite a lot of allocations, and this is causing some serious
trouble because marking cannot compete with the rate of allocation,
causing some tests to allocate a lot of memory, slowing down marking
even more. I'm still looking for a solution...
Well ultimatively you got to throttle your mutators to a throughput that
the GC can handle. That's actually a nice thing about the forking GC,
the mutator has to pay for the COW page faults, so there is some
How does your GC work?
There's sort of a description here:
There are actually two variations:
- one uses "Memory-Write-Watches" to detect modified pages and rescans
all pages modified during a background scan. It could be improved to
reschedule the second scan to the background, again, until there are
only few modified pages.
- the other uses COW protection on the pool memory, but has to copy
modified memory back when restoring unprotected memory mappings.