GC Blacklisting

[dsimcha]

== Quote from Vladimir Panteleev (vladimir at thecybershadow.net)'s article
> How can you be so sure this is enough? The particular manifestation of the
> bug I was examining crashed my application 5 hours in, because the GC
> attempted to traverse a free list which had ASCII in it because the item
> had been allocated but it occured in the free list twice (so the first
> instance was used by the app to store text), because a freed (GC'd) object
> was manually deleted again when an element was removed from an associated
> array, and it was freed initially because the GC never reached it, because
> its "parent" was marked as NOSCAN, because the GC relies on NOSCAN being
> cleared on freed objects, and allocating in a destructor called during a
> GC breaks that assumption (and messes things up generally).
> Are you at least running your tests with the GC debug options enabled
> (such as MEMSTOMP)? I hope your patches don't break them, either.
> In case you missed my other reply, what I was aiming at is that something
> must be done when allocating from destructors. It must either reliably
> work or immediately fail, and definitely not corrupt the GC's state.
> Phobos allocates in destructors in a few places as well (std.zlib being
> one).

Ok, I didn't realize how deep into debugging this you had gotten.  Thanks for your
work.  BTW, of course it's (practically) impossible to **prove** that the GC is
correct and that there aren't any subtle corner case bugs, but the point is that
testing on lots of real world code with completely different allocation patterns
helps a ton.  Ironically, for code that has lots of possible states and codepaths,
"regular" unittests don't work well because it's virtually impossible to think of
all the possible cases that real world code brings to the table.

Also, the GC is currently (pre-patches) so slow that it's practically unusable on
large (multi-gigabyte) heaps, to a large extent defeating the purpose of 64-bit
support.  This is, IMHO, a **severe** bug in itself, and is worth taking some
risks to fix.