Conspiracy Theory #1

[Denis Koroskin]

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?