Compiling the program I'm working on, dmd require more than 2Gb of memory. Looking at the memory consumption, it doesn't look like anything is freed.
I don't use a lot of CTFE. Many templates, but most of them are not recursive. Compilation time and resource really is becoming an issue. 2012/11/11 Daniel Murphy <[email protected]> > Yes, it's very easy to make it run out of memory with ctfe or recursive > templates. > > The garbage collector works as far as I know, but needs some performance > tuning. > > > On Sun, Nov 11, 2012 at 7:06 PM, David Held <[email protected]> wrote: > >> I see. And does anyone report running out of memory due to this? It >> seems like it would mostly be a problem with CTFE, but could be a problem >> on any large project, I suppose. >> >> Dave >> >> >> >> On 11/10/2012 11:34 PM, Daniel Murphy wrote: >> >> This isn't a bug, dmd does not free memory (with some exceptions), it >> assumes a garbage collector is present. >> >> On Sun, Nov 11, 2012 at 6:26 PM, David Held <[email protected]> wrote: >> >>> While writing some unit tests for Dsymbol, I noticed that >>> Dsymbol::toPrettyChars() leaks almost everywhere. In the simple case where >>> a symbol has no parent, it just returns toChars(), which does not leak (at >>> least I don't think it does). However, whenever the symbol has a parent >>> (or many), the returned string is composed, which requires that it is >>> allocated dynamically (via mem.malloc()). Even though the caller owns the >>> string, and even though it is called dozens of times, it appears that none >>> of the callers are properly disposing of the result. Unfortunately, it is >>> a bit messy to do so, because you must free the string *only* if it has a >>> parent, which is a pretty bad implementation leak, IMO. Here is a place >>> where std::string would have worked nicely. ;) >>> >>> I suspect this has gone unnoticed because A) dmd probably has a >>> relatively small memory footprint to begin with or B) most invokations of >>> toPrettyChars() are during a call to error(), so the compiler is about to >>> quit anyway. What to do? Leave it alone? Try to fix it? Note that >>> fixing it without changing toPrettyChars() would require adding 2-3 lines >>> of code to almost every call. >>> >>> Dave >>> >>> >>> P.S. Incidentally, this bug is one that is not easily caught with >>> assertions (where would you place the assert that the string was freed?). >>> Fortunately, it is caught by unit testing; but it could also have been >>> caught by documenting that the caller owns the string. This is why you >>> really want all 3 approaches to code quality. >>> >>> _______________________________________________ >>> dmd-internals mailing list >>> [email protected] >>> http://lists.puremagic.com/mailman/listinfo/dmd-internals >>> >> >> >> >> _______________________________________________ >> dmd-internals mailing >> [email protected]http://lists.puremagic.com/mailman/listinfo/dmd-internals >> >> >> >> _______________________________________________ >> dmd-internals mailing list >> [email protected] >> http://lists.puremagic.com/mailman/listinfo/dmd-internals >> > > > _______________________________________________ > dmd-internals mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-internals >
_______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
