www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9094] New: GC not collecting under Windows

reply d-bugmail puremagic.com writes:
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



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: -------
Nov 28 2012
next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Nov 28 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9094


Jacob Carlborg <doob me.com> changed:

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





 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: -------
Nov 28 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9094




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: -------
Nov 29 2012