http://d.puremagic.com/issues/show_bug.cgi?id=9094

           Summary: GC not collecting under Windows
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: druntime
        AssignedTo: nobody@puremagic.com
        ReportedBy: acehreli@yahoo.com


--- Comment #0 from Ali Cehreli <acehreli@yahoo.com> 2012-11-28 11:05:36 PST ---
Have a 1G file named "one_gigabyte_file". You can use the following program to create it:

import std.stdio;

void foo()
{
    auto file = File("one_gigabyte_file", "w");
    auto data = new ubyte[](100 * 1024 * 1024);

    foreach (i; 0 .. 10) {
        file.rawWrite(data);
    }
}

void main()
{
    foo();
}

Then, run the following program:

import std.stdio;

void foo()
{
    auto file = File("one_gigabyte_file", "r");
    auto data = new ubyte[](100 * 1024 * 1024);

    foreach (i; 0 .. 10) {
        file.rawRead(data);
    }
}

void main()
{
    for (size_t i; true; ++i) {
        writeln(i);
        foo();
    }
}

The problem is, the memory consumption of the program grows continuously until it is terminated by core.exception.OutOfMemoryError.

We don't see this issue under Linux.

Thank you,
Ali

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9094


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |WONTFIX


--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> 2012-11-28 18:05:14 PST ---
The garbage collector is completely unsuited for managing gigantic allocations like these. The reason is that a 1 gig allocation consumes 25% of the 32 bit address space.

Since the GC is a conservative mark-sweep one, 25% of any random bit patterns are going to be assumed to be a reference into those allocations, preventing them from being collected.

The only way out of this is with precise GC for everything, including the stack and static data segments. This will be impractical to achieve, if for no other reason than making it hard to interoperate with C code when sharing pointers between C and D.

Such large allocations need to be manually managed, with something like malloc/free. I don't see this changing in the near future.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9094


Jacob Carlborg <doob@me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob@me.com


--- Comment #2 from Jacob Carlborg <doob@me.com> 2012-11-28 23:28:33 PST ---
(In reply to comment #1)

> The only way out of this is with precise GC for everything, including the stack and static data segments. This will be impractical to achieve, if for no other reason than making it hard to interoperate with C code when sharing pointers between C and D.

Isn't it possible to do some kind of special treatment when integrating with C. I'm talking about the developer need to do something special, i.e. call GC.addRoot or similar. I don't think we should limit pure D programs, if possible.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9094



--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> 2012-11-29 02:17:27 PST ---
Yes, it's possible, but D has set a store by easy interoperability with C, and my experience is that having a protocol like that is doomed to misuse and bugs.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------