Concern about dmd memory usage on win32

[Nick Sabalausky]

On Fri, 07 Dec 2012 08:23:06 -0800
Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Friday, December 07, 2012 15:23:36 monarch_dodra wrote:
> > In particular, when compiling "-unittest std\algorithm.d", dmd
> > uses *nearly* 1 GB (it uses about 1,051,176K on my machine).
> > 
> > Problem is that when it reaches 1GB, it crashes. I have a pull
> > request which adds a few unittests to algorithm, and it is
> > consistently crashing on win32 with an out of memory error.
> > 
> > In layman's terms: std\algorithm.d is full. You literally can't
> > add any more unittests to it, without crashing dmd on win32.
> > 
> > I'd have recommended splitting the unittests in sub-modules or
> > whatnot, but come to think about it, I'm actually more concern
> > that a module could *singlehandedly* make the compiler crash on
> > out of memory...
> > 
> > Also, I'm no expert, but why is my dmd limited to 1 GB memory on
> > my 64 bit machine...?
> 
> If you look in win32.mak, you'll see that the source files are split
> into separate groups (STD_1_HEAVY, STD_2_HEAVY, STD_3, STD_4, etc.).
> This is specifically to combat this problem. Every time that we reach
> the point that the compilation starts running out of memory again, we
> add more groups and/or rearrange them. It's suboptimal, but I don't
> know what else we can do at this point given dmd's limitations on
> 32-bit Windows.
> 

Sooo...what's the status of fixing DMD's forever-standing memory usage
issues?

My understanding is that the big issues are:

1. CTFE allocates every time a CTFE variable's value is changed.

2. The GC inside DMD is disabled because it broke things, so it never
releases memory.

Is this correct? If so, what's the current status of fixes? It seems to
me this would be something that should be creeping higher and higher up
the priority list (if it hasn't already been doing so).