Analysis of D GC

[Dmitry Olshansky via Digitalmars-d]

On Tuesday, 20 June 2017 at 04:35:27 UTC, ketmar wrote:
> 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.

Since we are in control of what child does I see this as no 
issue. Just call mmap and do bump a pointer allocation.