GC API: What can change for precise scanning?

Walter Bright newshound2 at digitalmars.com
Wed Apr 18 13:13:06 PDT 2012


On 4/17/2012 5:36 PM, dsimcha wrote:
> Now that the compiler infrastructure has been implemented, I've gotten busy
> figuring out how to make D's default GC precise. As a first attempt, I think I'm
> going to adapt my original solution from
> http://d.puremagic.com/issues/show_bug.cgi?id=3463 since it's simple and it
> works except that there previously was no clean way to get the offset info into
> the GC. As Walter pointed out in another thread, the GCInfo template is allowed
> to instantiate to data instead of a function. IMHO unless/until major
> architectural changes to the GC are made that require a function pointer,
> there's no point in adding this indirection.
>
> I started working on this and I ran into a roadblock. I need to know what parts
> of the GC API are allowed to change, and discuss how to abstract away the
> implementation of it from the GC API. I assume the stuff in core.memory needs to
> stay mostly the same, though I guess we would need to add a setType() function
> that takes a pointer into a block of memory and a TypeInfo object and changes
> how the GC interprets the bits in the block.
>
> In gc.d, we define a bunch of extern(C) functions and the proxy thing. Since
> we've given up on the idea of swapping precise GCs at link time, can I just rip
> out all this unnecesary indirection? If not, is it ok to change some of these
> signatures? I definitely want to avoid allocating (requiring the GC lock) and
> then calling a function to set the type (requiring another lock acquisition) so
> the signature of malloc(), etc. needs to change somewhere.
>
> More generally, what is the intended way to get GCInfo pointers from TypeInfo
> into the guts of the GC where they can be acted on?

1. I would not try to redesign everything and do precise gc at the same time.

2. The purpose of the indirection is to support DLLs so that the different DLLs 
can share an instance.

3. The reason for function pointers for marking is so that the marking code can 
be customized and directly inlined, rather than decoding a table. It costs one 
code indirection, but after that it cannot be beaten for speed.


More information about the Digitalmars-d mailing list