[Issue 18005] AA leak
https://issues.dlang.org/show_bug.cgi?id=18005 Rainer Schuetze changed: What|Removed |Added Status|NEW |RESOLVED CC||r.sagita...@gmx.de Resolution|--- |FIXED --- Comment #5 from Rainer Schuetze --- The behavior varies across platforms because it very much depends on the actual addresses returned by the OS for allocating memory: linux prefers addresses at the top of the possible addressrange (2^^47) while windows uses returns low addresses above a couple GB (but not reproducable due to randomization). OSX is even worse as it starts with very addresses. In the reporte example, a wide range of low addresses are written into the (key,value) pairs of an AA. As the key is a string, it contains indirections that need to be scanned, i.e. the full allocation is scanned by a conservative GC. Precise GC to the rescue: when calling the build with "--DRT-gcopt=gc:precise --DRT-scanDataSeg=precise" as of dmd2.085, even for win32 it behaves as the linux build. I guess this is the best we can do, so closing... --
[Issue 18005] AA leak
https://issues.dlang.org/show_bug.cgi?id=18005
radu.raca...@gmail.com changed:
What|Removed |Added
CC||radu.raca...@gmail.com
--- Comment #4 from radu.raca...@gmail.com ---
don't think is the AA that does it, as the following exposes the same behavior:
+++
void main(string[] args)
{
foreach (i; 0..300)
{
import core.memory;
import std.stdio : writefln;
writefln(`%g MB used, %g MB free`, GC.stats.usedSize / 1024f / 1024,
GC.stats.freeSize / 1024f / 1024);
new bool[13 * 1024 * 1024]; // <- this collects differently on Windows
GC.collect;
GC.minimize;
}
}
+++
Running it:
0.000137329 MB used, 0.999863 MB free
13.004 MB used, 7.49988 MB free
26.0079 MB used, 13. MB free
39.0118 MB used, 20.4999 MB free
52.0157 MB used, 26. MB free
65.0197 MB used, 33.4999 MB free
78.0236 MB used, 39. MB free
78.0236 MB used, 42.496 MB free
91.0275 MB used, 51.4921 MB free
104.031 MB used, 63.4882 MB free
104.031 MB used, 66.4882 MB free
117.035 MB used, 53.4843 MB free
130.039 MB used, 68.4803 MB free
143.043 MB used, 55.4764 MB free
143.043 MB used, 86.4764 MB free
143.043 MB used, 55.4764 MB free
143.043 MB used, 86.4764 MB free
143.043 MB used, 55.4764 MB free
143.043 MB used, 86.4764 MB free
143.043 MB used, 55.4764 MB free
143.043 MB used, 86.4764 MB free
143.043 MB used, 55.4764 MB free
143.043 MB used, 86.4764 MB free
143.043 MB used, 55.4764 MB free
143.043 MB used, 86.4764 MB free
It stabilizes at 143.043 MB
On Linux it collects eagerly and stabilizes around
13.0042 MB used, 7.49976 MB free
--
[Issue 18005] AA leak
https://issues.dlang.org/show_bug.cgi?id=18005 --- Comment #3 from Steven Schveighoffer --- There's nothing different on Windows vs. Linux with regards to the AA implementation. Both are abstracted against the GC. So if this is 64-bit windows, the only attribute I can think of to associate with this behavior is the numbers the OS assigns to stacks/heaps happen to coincide with the pointers that are there. (In reply to Temtaime from comment #2) > Also there's NO_SCAN attribute so there should not be any. Doesn't matter. The stack is not NO_SCAN, and the AA bucket elements are not NO_SCAN. What you are doing is making large targets (13MB targets) that these false pointers may hook onto. The nature of false pointers is that in certain situations, they happen, and changing seemingly random things can affect it. Not sure if we will get to the bottom of this, or even solve it. --
[Issue 18005] AA leak
https://issues.dlang.org/show_bug.cgi?id=18005 --- Comment #2 from Temtaime --- Yes. Also there's NO_SCAN attribute so there should not be any. --
[Issue 18005] AA leak
https://issues.dlang.org/show_bug.cgi?id=18005 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer --- Are you using -m64 on windows? 32-bit OSes are well known for having memory leaks due to false pointers. --
