GC Blacklisting

[dsimcha]

== Quote from Vladimir Panteleev (vladimir at thecybershadow.net)'s article
> P.S. I'm currently in the process of tracking down a memory corruption
> bug, which *might* result in a GC patch for D1. I'm also instinctively
> worried that touching the GC code may introduce new memory corruption
> bugs, which can be EXTREMELY hard to find. I've been chasing this one for
> 4 years.

I doubt it's a GC bug.  If it's not a bug in your code, I'd be more inclined to
assume it's a codegen bug, simply because the codegen is much larger and more
complex, and there are more opportunities for weird bugs that can only be
reproduced under very specific circumstances to creep in.  Once you get past the
superficial cruftiness and unreadability of the codebase and get a good conceptual
model of it, D's GC is actually pretty simple.

Also, I've been testing my patches by using the Phobos,
std.parallelism/parallelfuture, and dstats unittests, and by simply eating my own
dogfood (i.e. using my modified GC's when running some simulations and stuff).  So
far, so good.  Unfortunately, we don't have a specific GC test suite, but IMHO if
it works on this much real-world code, it's unlikely that I've created any bugs.