digitalmars.D.bugs - [Issue 7251] New: GC not working
- d-bugmail puremagic.com Jan 08 2012
- d-bugmail puremagic.com Jan 09 2012
- d-bugmail puremagic.com Feb 29 2012
- d-bugmail puremagic.com Mar 01 2012
- d-bugmail puremagic.com Mar 01 2012
- d-bugmail puremagic.com Mar 01 2012
- d-bugmail puremagic.com Mar 01 2012
- d-bugmail puremagic.com Mar 04 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7251 Summary: GC not working Product: D Version: D2 Platform: x86 OS/Version: Windows Status: NEW Severity: regression Priority: P2 Component: druntime AssignedTo: nobody puremagic.com ReportedBy: wfunction hotmail.com --- Comment #0 from wfunction hotmail.com 2012-01-08 23:40:33 PST --- On DMD 2.057, the code: import core.memory, std.stdio; extern(Windows) int GlobalMemoryStatusEx(ref MEMORYSTATUSEX lpBuffer); struct MEMORYSTATUSEX { uint Length, MemoryLoad; ulong TotalPhys, AvailPhys, TotalPageFile, AvailPageFile; ulong TotalVirtual, AvailVirtual, AvailExtendedVirtual; } void testA(size_t count) { size_t[] a; foreach (i; 0 .. count) a ~= i; } void main() { MEMORYSTATUSEX ms; ms.Length = ms.sizeof; foreach (i; 0 .. 32) { testA(16 << 20); GlobalMemoryStatusEx(ms); stderr.writefln("AvailPhys: %s MiB", ms.AvailPhys >>> 20); } } Gives output: AvailPhys: 3711 MiB AvailPhys: 3365 MiB AvailPhys: 3061 MiB AvailPhys: 2747 MiB AvailPhys: 2458 MiB core.exception.OutOfMemoryError Obviously, the GC is non-functional... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 08 2012
d-bugmail puremagic.com http://d.puremagic.com/issues/show_bug.cgi?id=7251 David Simcha <dsimcha yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |dsimcha yahoo.com Resolution| |INVALID --- Comment #1 from David Simcha <dsimcha yahoo.com> 2012-01-09 14:47:00 PST --- This looks like false pointers. testA allocates 48 MB for its largest array on each run. We really need precise heap scanning. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 09 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7251 wfunction hotmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #2 from wfunction hotmail.com 2012-02-29 20:08:19 PST --- Just wondering, why was this marked as "Resolved, Invalid" with no comment? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 29 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7251 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |clugdbug yahoo.com.au Resolution| |INVALID --- Comment #3 from Don <clugdbug yahoo.com.au> 2012-03-01 01:22:39 PST --- (In reply to comment #2)Just wondering, why was this marked as "Resolved, Invalid" with no comment?
Huh? Comment #1 was added when it was closed. Reclosing. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7251 wfunction hotmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |REMIND --- Comment #4 from wfunction hotmail.com 2012-03-01 02:01:33 PST --- (In reply to comment #3)(In reply to comment #2)Just wondering, why was this marked as "Resolved, Invalid" with no comment?
Huh? Comment #1 was added when it was closed. Reclosing.
Wait what? "This looks like false pointers [...] We really need precise heap scanning." Doesn't that mean this needs to be fixed? Or is one of us misunderstanding the meaning of the above? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7251 --- Comment #5 from Don <clugdbug yahoo.com.au> 2012-03-01 03:39:55 PST --- (In reply to comment #4)(In reply to comment #3)(In reply to comment #2)Just wondering, why was this marked as "Resolved, Invalid" with no comment?
Huh? Comment #1 was added when it was closed. Reclosing.
Wait what? "This looks like false pointers [...] We really need precise heap scanning." Doesn't that mean this needs to be fixed? Or is one of us misunderstanding the meaning of the above?
No, it's inevitable that a mark-and-sweep GC on a 32 bit system won't work if large numbers of false pointers are present. And this code: foreach (i; 0 .. count) a ~= i; is flooding the system with false pointers. You marked this as regression, is there any previous compiler where this worked? (reopen if it there is). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7251 --- Comment #6 from wfunction hotmail.com 2012-03-01 14:53:44 PST --- (In reply to comment #5)No, it's inevitable that a mark-and-sweep GC on a 32 bit system won't work if large numbers of false pointers are present. And this code: foreach (i; 0 .. count) a ~= i; is flooding the system with false pointers.
I think you might have misunderstood the problem, like I originally did. I am ********** NOT *********** filling the system with false pointers. See David Simcha's comment in response to mine: http://stackoverflow.com/a/8796226/541686 It's inherently defective -- I'm merely _allocating_ a lot of memory, that's all. The rest is a problem with the GC's algorithm. (Unless you expect that no one will allocate one 20-MB chunk of RAM?)You marked this as regression, is there any previous compiler where this worked? (reopen if it there is).
I marked it as "remind", since I'm sorta reminding about this bug... if that's not the implied meaning then my bad, but this still needs to be fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7251 Rob Jacques <sandford jhu.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P4 CC| |sandford jhu.edu Platform|x86 |All OS/Version|Windows |All Severity|regression |minor --- Comment #7 from Rob Jacques <sandford jhu.edu> 2012-03-04 09:53:01 PST --- (In reply to comment #6)(In reply to comment #5)No, it's inevitable that a mark-and-sweep GC on a 32 bit system won't work if large numbers of false pointers are present. And this code: foreach (i; 0 .. count) a ~= i; is flooding the system with false pointers.
I think you might have misunderstood the problem, like I originally did. I am ********** NOT *********** filling the system with false pointers. See David Simcha's comment in response to mine: http://stackoverflow.com/a/8796226/541686 It's inherently defective -- I'm merely _allocating_ a lot of memory, that's all. The rest is a problem with the GC's algorithm. (Unless you expect that no one will allocate one 20-MB chunk of RAM?)
The static data segment and the stack generate _always_ contain false pointers. So even if you're not generating them yourself much, they do exist and things will get stuck. Also, direct use of ~= is discouraged; appender is recommended instead and there patch for appender that solves this issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 04 2012