Analysis of D GC

[safety0ff via Digitalmars-d]

On Monday, 19 June 2017 at 22:35:42 UTC, Dmitry Olshansky wrote:
>
> http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html
>
> "But the main unanswered question is why? Why an extra pass?"

It's likely to pave over the many pitfalls of D finalizers.

E.g. finalizers corrupting data:
class A { size_t i; }
class B { A a; this(){ a = new A; } ~this() { a.i = 1; } }
// modifying B.a.i is undefined behavior (e.g. it could corrupt 
the GC's freelist)

E.g. finalizers reading undefined data:
class A { virtual bool check() { return true; } }
class B { A a; this(){ a = new A; } ~this() { a.check(); } }
// B.a's object header is undefined (e.g. replaced with GC 
freelist pointer)

There's also invariants, which are prepended to the finalizers, 
so their code is subject to the same issues.

The best thing about the current implementation is that object 
resurrection has never been supported.