Problems with GC, trees and array concatenation
Oskar Linde
oskar.lindeREM at OVEgmail.com
Fri Jun 1 10:08:28 PDT 2007
Babele Dunnit wrote:
> Hello everybody,
>
> I had a HELL of a day to understand what was wrong and to strip it out from my sources, but now I got it. Run this and keep an eye on the Task Manager: your memory will be eaten until death. Please note that:
>
> 1) the keys of it all seems to be the "recursive" Individual class (I was playing with trees). Substitute the
>
> class Individual
> {
> Individual[20] children;
> }
>
> with a
>
> class Individual
> {
> real[20] values;
> }
>
> and the GC will work flawlessly.
>
> 2) please note that I am using static arrays, but dynamic arrays behave in the same way.
>
> 3) If you use array slicing and direct assignments everything is OK. Please try both "loseMemory" and "everythingOk" versions.
I tried both with GDC 0.23 on OSX, and neither of them leaked any
memory, so I can only speculate about what is causing this. The D GC is
not precise (although it has become much better since 1.001). There will
almost always be some spurious pointers. Allocating large arrays (such
as what happens behind the scenes when doing array concatenation) will
always carry a risk of allocated memory being hit by a spurious pointer.
The risk of your application having runaway or contained memory leaks
depend on the allocation patterns you have, but in general, the larger
your objects (like arrays) are, the larger the chance that you need to
handle their memory manually. The problem is increased if you have many
objects containing mixed pointer and non-pointer, but apparantly random
data.
So in conclusion, I am quite sure the following line:
indi[] = testPop1.individuals ~ testPop2.individuals;
Is the cause of the memory leak, because it allocates a huge chunk of
memory that is left to the GC to free. The chance of those huge chunks
being hit by a spurious pointer seems quite high.
I have no idea why the Individual->real substitution above would make
any difference, if not by pure chance.
/Oskar
More information about the Digitalmars-d
mailing list