Conspiracy Theory #1

[Travis Boucher]

dsimcha wrote:
> == Quote from Denis Koroskin (2korden at gmail.com)'s article
>> On Fri, 20 Nov 2009 17:28:07 +0300, dsimcha <dsimcha at yahoo.com> wrote:
>>> == Quote from Travis Boucher (boucher.travis at gmail.com)'s article
>>>> dsimcha wrote:
>>>>> == Quote from Travis Boucher (boucher.travis at gmail.com)'s article
>>>>>> Sean Kelly wrote:
>>>>>>  Its harder
>>>>>> to create a memory leak in D then it is to prevent one in C.
>>>>> void doStuff() {
>>>>>     uint[] foo = new uint[100_000_000];
>>>>> }
>>>>>
>>>>> void main() {
>>>>>     while(true) {
>>>>>         doStuff();
>>>>>     }
>>>>> }
>>>>>
>>>> Hmm, that seems like that should be an implementation bug.  Shouldn't
>>>> foo be marked for GC once it scope?  (I have never used new on a
>>>> primitive type, so I don't know)
>>> It's conservative GC.  D's GC, along with the Hans Boehm GC and probably
>>> most GCs
>>> for close to the metal languages, can't perfectly identify what's a
>>> pointer and
>>> what's not.  Therefore, for sufficiently large allocations there's a high
>>> probability that some bit pattern that looks like a pointer but isn't
>>> one will
>>> keep the allocation alive long after there are no "real" references to
>>> it left.
>> Aren't uint array allocations have hasPointers flag set off? I always
>> thought they aren't scanned for pointers (unlike, say, void[]).
> 
> Right, but they can still be the target of false pointers.  In this case, false
> pointers keep each instance of foo[] alive, leading to severe memory leaks.

But the issue is more of a GC implementation issue then a language 
issue, correct?  Or is this an issue of all lower level language garbage 
collectors?

I do not know much about GC, just basic concepts.