GC API: What can change for precise scanning?

[deadalnix]

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).