Conspiracy Theory #1

[Travis Boucher]

Denis Koroskin wrote:
> 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?

Probably not since the bit pattern of int i could still match a valid 
pointer.

Foo.i = cast(int)&Foo;   // for bad practice ugliness

or Foo.i = (some expression that happens to equal &Foo)


Adding extra information to a union could also have the bad side effect 
of killing performance as writes would include an extra write, and 
additional memory would be required (which would cause another set of 
issues on how to handle alignment).