GC conservatism -- again

[Johan Granberg]

Sean Kelly wrote:

> Ulrik Mikaelsson Wrote:
> 
>> > I have posted about this problem several times. Never got any replies.
>> > I think memory management is D's "elephant in the room" in this regard.
>> I'm sorry to agree. I recently brought up this general question in a
>> thread called "Mixing GC and non-GC in D." in both druntime and here.
>> Only got one answer each in both druntime and this group. The problem
>> basically, from all I've read about GC:s in general and the D GC in
>> particular, is the problem of non-deterministic collection, both when
>> and more importantly IF the object will ever be collected. This makes
>> the GC unsuitable for "expensive" resources, such as file descriptors,
>> or very big chunks of memory.
> 
> 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.
> 
>> 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.

Acctually I think one reason for low intrest on the druntime list is that
people simply have not heard of it. I for one hasn't. I personally think
more people would read it if it was just another news group on the
digitalmars server. There might be other benefits for doing it the current
way ofcurse.