On Apr 16, 2012, at 7:20 PM, Andrei Alexandrescu <[email protected]> wrote:
> On 4/16/12 1:02 PM, Sean Kelly wrote: >> As for pointer maps, I think it's reasonable to establish a format >> that these will be made available to the GC, and for them to come >> from elsewhere in the runtime. I realize that different GC >> implementations may prefer different formats, but hopefully we can >> settle on one that's pretty generally usable and efficient. I'd >> really rather avoid expecting GC writers to know how to meta-process >> D types to statically generate this themselves. Moving this into the >> GC would also eliminate the possibility of having the GC chosen at >> link-time, which is something that's currently still an option. > > I know you didn't mean it that way, but this gets close enough to a dogma to > warrant a protest. "We don't need no steenkin' templates in <sacred area X>" > is, I think, an attitude we need to just rid ourselves of. There's the same > harm in using templates too much or too little. > > The scheme Walter proposed has a lot of flexibility - it plants one pointer > to function per type. This is very flexible because that pointer could point > to the same function and use a bitmap-based scheme, or (as Walter proposed) > point to different instances of a template that does scanning in a > type-specific manner. Fair enough. How about core.memory? That's the visible GC interface, and would be where template-based GC methods are defined. It still limits all GC implementations to a single pointer map representation though, without some theatrics.
