The problem with the D GC

%u dusr at yahoo.com
Mon Jan 8 22:38:44 PST 2007


== Quote from Bill Baxter (dnewsgroup at billbaxter.com)'s article
> Here's a slightly less contrived version of Oskar's gc test.
> import std.math;
> import std.random;
> import std.stdio;
> void main() {
>      // The real memory use, ~40 mb
>      double[] data;
>      data.length = 5_000_000;
>      foreach(i, inout x; data) {
>          x = sin(cast(double)i/data.length);
>          //x = 1;
>      }
>      int count = 0;
>      int gcount = 0;
>      while(1) {
>          // simulate reading a few kb of data
>          double[] incoming;
>          incoming.length = 1000 + rand() % 5000;
>          foreach(i, inout x; incoming) {
>              x = sin(cast(double)i/incoming.length);
>              //x = 5;
>          }
>          // do something with the data...
>          // print status message every so often
>          count += incoming.length;
>          if (count > 1_000_000) {
>              count = 0;
>              gcount++;
>              writefln("%s processed", gcount);
>          }
>      }
> }
> This one uses doubles instead of uints and the data is the sin of some
> number.  These are _very_ realistic values for numeric data to have.
> The same effect can be seen.  Instead of hovering around 40MB, the
> memory use grows and grows and performance slows and slows.
> This seems to be a very big issue.  The GC seems to be pretty much
> useless right now if you're going to have a lot of floating point data
> in your app.
> --bb
> Oskar Linde wrote:
> > After having fought a while with D programs with runaway memory leaks,
> > I've unfortunately had to come to the conclusion that the D GC is not
> > ready for production use. The problem is what I'd call "spurious
> > pointers". That is random data (strings, numbers, image data, audio or
> > whatever) appearing to the GC to be full of pointers to all over the
> > memory space.
> >
> > Consider this simple program. It is designed to have a memory footprint
> > of about 20 mb and then continuously process data.
> >

Agreed. This needs to be changed. Is the GC in that tango
library any better?



More information about the Digitalmars-d mailing list