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.
_______________________________________________
dmd-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals
