The problem with the D GC

[Kyle Furlong]

Frits van Bommel wrote:
> Ralf Schneider wrote:
>> It dosen't seem so hard for me to let the compiler set such an 
>> attribute on arrays without pointers...
> 
> It's pretty hard if you can't modify the compiler ;).
> Sean can't modify what DMD does (at least, not directly). He _can_ 
> (directly) modify what the runtime library does by replacing it, which 
> is what he's done.
> He (or anyone else, for that matter) might be able to implement this in 
> GDC though...
> And Walter might be convinced to implement it in DMD (or, if it's 
> front-end only code, accept a patch that implements it).
> 
> Of course, that still leaves arrays of structs, which may contain both 
> pointers and non-pointers.
> What we really need is a way for the GC to know what the type of the 
> memory is, or at least where the pointers are. This may be possible by 
> adding this info to TypeInfo & subclasses[1]. But then every memory 
> block would need a pointer to the relevant TypeInfo (or some condensed 
> form of this information, like flags for "only pointers" and "no 
> pointers", with TypeInfo pointer only if both are false).
> This would definitely require some sort of compiler support though; it 
> would need to generate appropriate type information for structs, objects 
> (the actual memory, not the references) and unions.
> It would then need to supply this information to the GC in the runtime, 
> requiring extra code generation.
> 
> 
> [1]: This could be as simple as supplying a member function that 
> performs a callback for every offset containing a pointer.

According to a conversation I had with Walter a month or two ago, this 
is the direction we are going. With this sort of type information, 
other, more modern GC implementations will become possible, one of which 
I hope to write. :D