Analysis of D GC

[ketmar via Digitalmars-d]

H. S. Teoh wrote:

> He mentioned the "fork trick", which I assume refers to how Linux's
> implementation of fork() uses copy-on-write rather than immediately
> duplicating the parent process' memory structures.  There was a D1 GC
> some time ago that depended on this behaviour to speed up the collection
> cycle.

and it was even ported to D2, and worked. sadly, using `fork()` has it's 
own set of problems -- `fork()` itself is in no way  a flawless expirience. 
like you can fork while other thread is inside glibc's `malloc()`, and 
BOOM! alot of glibc is locked forever, as `malloc()` lock is never released 
in child process. some other libraries may try to intercept `fork()` to 
do unnecessary "cleanup", and so on.

so using "forking GC" require alot of discipline in coding and library use, 
or it will be an endless source of heisenbugs.

new linux kernels got userfaultfd API (so code can simply `select()` on fd, 
and process protection violation from `mprotect()` without tricks with 
signals), but... to much of my joy and hapiness, the proposed API was just 
fine to create GC with mprotect barriers, and the final API that was 
included gladly omited that exactly necessary API call which allows to make 
it happen. great work, yeah. it may changed since then, tho, i didn't 
rechecked.