Garbage collector memory leak "feature"?

[Bill Baxter]

Steven Schveighoffer wrote:
> "0ffh" wrote
>> Steven Schveighoffer wrote:
>>> "0ffh" wrote
>>> But why should the GC have to worry about pointers in random data?  My 
>>> question is, is there a *need* for the GC to assume any data could be a 
>>> pointer, does any code actually *depend* on that behavior?  I really 
>>> would like to see an example of where it is necessary.
>> Well, we are not just talking about random data, but of data which is
>> excplicitly defined as "data of random type, including pointers".
>> It is a feature, not a bug; and not incidentally, but planned this way.
> 
> OK, I understand it is planned this way.  I even understand the rationale 
> behind it.  But this is more of a "functions as designed" feature than a 
> real feature.  I'm sure the writer of the GC did not intend for this side 
> effect to occur.
> 
> I think we are way off track here.  There is a problem with the garbage 
> collector in that it can assume data that is not a pointer is a pointer, and 
> therefore not collect the data pointed to when it should.  It may be that 
> not scanning void[] is not the solution to the problem, but there is 
> definitely a problem.

Well a good start would be to fix phobos' AA implementation so that it 
doesn't generate so many false positives.  Tango improves on it some, 
but I wonder if Tango does ok on the test case here:
     http://d.puremagic.com/issues/show_bug.cgi?id=1561


> All I know is that if it's going to leak memory for no good reason that I 
> can see, then I don't want to use it in a production-quality product, 
> because not only is it impossible to tell whether it will leak data (note 
> that this problem is completely non-deterministic), but it is impossible to 
> FIX the problem without significantly paranoid code.  And oh by the way I 
> need to see all the source code to all libraries I use so that I don't 
> accidentally use something that contains a void *.

Better diagnostic tools would help.  If you could run a memory profile 
and find out that the GC is keeping memory block A allocated here 
because this thing in memory block B allocated here is referring to it, 
then it would be much easier to find and fix these spurious references.

Also fixing it so the core library constructs don't generate spurious 
references would be nice too.  I don't think anyone expects a core 
language feature like AAs to interact poorly with another core langauge 
feature, the GC.

But hey, on the bright side, things have come a long way in D.  It used 
to be that just creating large buffers of floats could bring a system to 
its knees. :-)

--bb