GC API: What can change for precise scanning?

[Alex Rønne Petersen]

On 18-04-2012 11:56, deadalnix wrote:
> 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.

+1. This is useless if we're going to use bitmaps or similar.

>
> I think you certainly can remove all indirection. Additionally, I wonder
> why most of theses functions are extern(C).


-- 
- Alex