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.

Reply via email to