GC conservatism -- again

[Ulrik Mikaelsson]

> Sorry for not replying, I've had some personal issues recently that have taken up all of my time.  Your suggestion seemed workable for solving the dereferencing issue, but leaving the destroyed objects in an invalid state seems likely to cause weird bugs.  And the objects can't safely be reset to their initial state (ala. clear) after destruction for concurrency reasons.  So I'm not sure it will really help all that much in practice.  It wouldn't be a tremendous amount of work to try this out though.
On the druntime-list, it was also pointed out that the assumption that
related objects are collected either in the same run or in
reference-order are not true for all GC-types, I.E. not for
incremental GC:s. Therefore it seems like a bad semantic to impose on
the GC, in case someone wants other GC:s some day.

>> The problem I've encountered in D, is that support for complementary
>> predictable allocation schemes which could alleviate some of the
>> problems (i.e. reference-counting and tree-allocation), is quite weak.
>> By weak, I mean undocumented and no supporting framework from the
>> stdlib. In a perfect world, this could even work hand-in-hand with the
>> GC, such that references to refcounted-object could be voided from the
>> destruction of the reference-counted object.
> There's been some talk of doing this, but other things have had priority.
>
>> Is this a discussion that should be held in Phobos/Tango, druntime, or
>> on this list?
> The druntime list would be most appropriate, but it has very few members (partially because so few people are interested in this level of code, I suspect).  The most expedient solution would be to just write the code and submit a patch for evaluation.
>
FYI: I don't have access to build-env for D2/druntime, but I've
created an implementation for RefCounting for Tango, in
http://www.dsource.org/projects/tango/ticket/2024. It might be of
interest to port to druntime, with the mentioned D2-improvements to
SmartRef.