Bug 7251 – GC not working

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...

This looks like false pointers. testA allocates 48 MB for its largest array on each run. We really need precise heap scanning.

Just wondering, why was this marked as "Resolved, Invalid" with no comment?

(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.

(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?

(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).

(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.

(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.

I think is better to set this as a duplicate of #3463, as when that one gets fixed, this one should be fixed too. *** This issue has been marked as a duplicate of issue 3463 ***