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
built-in throttling.
How does your GC work?

There's sort of a description here: http://rainers.github.io/visuald/druntime/concurrentgc.html

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.

Reply via email to