The problem with the D GC

Sean Kelly sean at f4.ca
Tue Jan 9 14:41:34 PST 2007


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.

An interim alternative that came up in conversation would be to provide 
similar functionality via template functions.  With the .tupleof 
property, it's possible to obtain a very accurate picture of what data 
should be scanned.  This would mean using a custom function instead of 
'new', but it would certainly work:

     MyClass c = create!(MyClass)( a, b, c );

The create function above could be written using TypeTuples and other 
magic to allow direct parameter passing to the class ctor, making the 
routine just as efficient as an in-language solution.  Similar functions 
could be written for arrays, exploiting some tricks in the language:

     T[] resize(T)( T[] val, size_t len ) { ... }
     int[] buf;
     buf.resize( 1024 );

Again, perhaps not as clean as an in-language solution, but it could be 
done today.

I'll look into doing something like this for Tango prior to release.  It 
shouldn't be too difficult, assuming the .tupleof property works as 
described (some experimentation I made this morning suggests that it may 
not).


Sean



More information about the Digitalmars-d mailing list