https://issues.dlang.org/show_bug.cgi?id=18005

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com

--- Comment #1 from Steven Schveighoffer <schveiguy@yahoo.com> ---
Are you using -m64 on windows? 32-bit OSes are well known for having memory leaks due to false pointers.

--

https://issues.dlang.org/show_bug.cgi?id=18005

--- Comment #2 from Temtaime <temtaime@gmail.com> ---
Yes.
Also there's NO_SCAN attribute so there should not be any.

--

https://issues.dlang.org/show_bug.cgi?id=18005

--- Comment #3 from Steven Schveighoffer <schveiguy@yahoo.com> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=18005

radu.racariu@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |radu.racariu@gmail.com

--- Comment #4 from radu.racariu@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.9999 MB free
39.0118 MB used, 20.4999 MB free
52.0157 MB used, 26.9999 MB free
65.0197 MB used, 33.4999 MB free
78.0236 MB used, 39.9999 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

--

https://issues.dlang.org/show_bug.cgi?id=18005

Rainer Schuetze <r.sagitario@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |r.sagitario@gmx.de
         Resolution|---                         |FIXED

--- Comment #5 from Rainer Schuetze <r.sagitario@gmx.de> ---
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...

--