[dmd-internals] Memory Leak

David Held dmd at wyntrmute.com
Wed Nov 14 00:38:33 PST 2012


On 11/13/2012 11:27 PM, Walter Bright wrote:
> [...]
> Since the GC is already there and works, I'd say it's easier to try 
> that route first. Some simple things I'd do to try and speed it up 
> that are specific to dmd:
>
> 1. disable all the threading lock code
>
> 2. tune it so it doesn't try to do a collection until more than 1Gb is 
> allocated

My understanding is that it's a mark/sweep collector.  Is that correct?  
Is it even feasible to implement a copying collector, or does dmd do 
dirty things with pointers that make that problematic? My understanding 
of GC is that mark/sweep is better if the number of surviving objects is 
large relative to the total pool, and copying is better if the number is 
small.  Does dmd tend to create mostly short-lived or long-lived objects?

Obviously the string table is long-lived, and I assume the symbol table 
as well.  It seems that most of the rest of the work is more 
short-lived.  If I'm right, then it probably isn't feasible to make the 
mark/sweep collector very fast/efficient, because it's spending too much 
time sweeping.

Of course, the generational model combines the best of both worlds, but 
somehow, I really doubt that the existing GC is generational. ;)

Dave



More information about the dmd-internals mailing list