[dmd-internals] Memory Leak

[Walter Bright]

On 11/14/2012 12:38 AM, David Held wrote:
> 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?

Yes.

>   Is it even feasible to implement a copying collector, or does dmd do dirty 
> things with pointers that make that problematic?

What makes it problematic is you cannot do a copying collector without having 
type info for all the references. C compilers do not generate that.

> 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?

I don't really know.

>
> 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. ;)


It isn't, and neither is the Boehm one.