Le 18/04/2012 02:36, dsimcha a écrit :
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?
I guess that the flag to indicate if some piece of memory may have
pointer can go away.
I think you certainly can remove all indirection. Additionally, I wonder
why most of theses functions are extern(C).
