== Quote from Denis Koroskin ([email protected])'s article > On Fri, 20 Nov 2009 17:28:07 +0300, dsimcha <[email protected]> wrote: > > == Quote from Travis Boucher ([email protected])'s article > >> dsimcha wrote: > >> > == Quote from Travis Boucher ([email protected])'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.
