Conspiracy Theory #1

[dsimcha]

== Quote from Denis Koroskin (2korden at gmail.com)'s article
> On Fri, 20 Nov 2009 19:24:05 +0300, dsimcha <dsimcha at yahoo.com> wrote:
> > == 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.
> Unions could be deprecated in favor of tagged unions (see an example in
> Cyclone http://cyclone.thelanguage.org/wiki/Tagged%20Unions). Would that
> help?

It would be negligible.  The idea is that unions of reference and non-reference
types are such a corner case that they could be handled conservatively as a
special case, and then it's possible, at least in principle, to deal with the
other 99.99999% of cases precisely and being conservative in 0.00001% of cases is
really of no practical significance.

Keep in mind that we would need to have the ability to pin and scan conservatively
anyhow, since a systems language must allow allocation of untyped blocks of memory.

I guess what I should have said is that the SafeD subset can be made 100% precise
and D as a whole can be made about 99+% precise.