Conspiracy Theory #1

[dsimcha]

== 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.