On Apr 7, 2012, at 6:56 PM, Walter Bright <newshou...@digitalmars.com> wrote:
> Of course, many of us have been thinking about this for a looong time, and > what is the best way to go about it. The usual technique is for the compiler > to emit some sort of table for each TypeInfo giving the layout of the object, > i.e. where the pointers are. > > The general problem with these is the table is non-trivial, as it will > require things like iterated data blocks, etc. It has to be compressed to > save space, and the gc then has to execute a fair amount of code to decode it. > > It also requires some significant work on the compiler end, leading of course > to complexity, rigidity, development bottlenecks, and the usual bugs. > > An alternative Andrei and I have been talking about is to put in the TypeInfo > a pointer to a function. That function will contain customized code to mark > the pointers in an instance of that type. That custom code will be generated > by a template defined by the library. All the compiler has to do is stupidly > instantiate the template for the type, and insert an address to the generated > function. > > The compiler need know NOTHING about how the marking works. > > Even better, as ctRegex has demonstrated, the custom generated code can be > very, very fast compared with a runtime table-driven approach. (The slow part > will be calling the function indirectly.) > > And best of all, the design is pushed out of the compiler into the library, > so various schemes can be tried out without needing compiler work. > > I think this is an exciting idea, it will enable us to get a precise gc by > enabling people to work on it in parallel rather than serially waiting for me. With __traits and such, I kind of always figured we'd go this way. There's simply no reason to have the compiler generate a map. Glad to see it's working out.
