Conspiracy Theory #1

[dsimcha]

== Quote from Travis Boucher (boucher.travis at gmail.com)'s article
> 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?

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.