digitalmars.D.bugs - [Issue 9094] New: GC not collecting under Windows
- d-bugmail puremagic.com (53/53) Nov 28 2012 http://d.puremagic.com/issues/show_bug.cgi?id=9094
- d-bugmail puremagic.com (23/23) Nov 28 2012 http://d.puremagic.com/issues/show_bug.cgi?id=9094
- d-bugmail puremagic.com (14/18) Nov 28 2012 http://d.puremagic.com/issues/show_bug.cgi?id=9094
- d-bugmail puremagic.com (7/7) Nov 29 2012 http://d.puremagic.com/issues/show_bug.cgi?id=9094
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=9094 Jacob Carlborg <doob me.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |doob me.comThe 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
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