== Quote from Travis Boucher ([email protected])'s article > dsimcha wrote: > > == 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. > But the issue is more of a GC implementation issue then a language > issue, correct?
Yes. > Or is this an issue of all lower level language garbage > collectors? Kinda sorta. It's possible, but not easy, to implement fully precise GC (except for the extreme corner case of unions of reference and non-reference types) in a close to the metal, statically compiled language.
