dsimcha wrote:
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
On Fri, 20 Nov 2009 17:28:07 +0300, dsimcha <dsim...@yahoo.com> wrote:
== Quote from Travis Boucher (boucher.tra...@gmail.com)'s article
dsimcha wrote:
== Quote from Travis Boucher (boucher.tra...@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? Or is this an issue of all lower level language garbage
collectors?
I do not know much about GC, just basic concepts.
