The problem with the D GC

%u u at digitaldaemon.com
Mon Jan 8 11:23:39 PST 2007


== Quote from Oskar Linde (oskar.lindeREM at OVEgmail.com)'s article
> This means that each time you rely on the GC (array
> appending/resizing, Phobos function calls etc), you have a
> potential memory leak.

Wrong. You have an intentional memory leak, from which the GC
cannot recover you.

The GC was designed to eventually free coders from memory leak
accidents. To enable this all variables are initialized by default--
-because this way no random data, including pointers, can survive.

In total your toy program establishes exactly that environment for
which the GC is known to fail.

There is an easy solution for such environments by increasing the
amount of memory needed for pointers by the factor two---or halving
the available memory if memory bounds are tight and one takes a
look from the other side.

But even this solution will not prevent the GC from sucking in all
data swapped out, if the GC is not coupled with the virtual memory
manager.



More information about the Digitalmars-d mailing list