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[]).
