(Semi) precise GC [was: Re: Std Phobos 2 and logging library?]

[Sean Kelly]

Leandro Lucarella wrote:
> Frits van Bommel, el 13 de abril a las 19:36 me escribiste:
>> Leandro Lucarella wrote:
>>> Frits van Bommel, el 13 de abril a las 13:30 me escribiste:
>>>>>> Or you can pin anything that's referenced from the stack, and move
>>>>>> anything that is only referenced from the heap.
>>>>> That's more likely to happen, but it requires a compiler change too
>>>>> (provide type information on allocation). Maybe I wasn't too clear,
>>>>> I didn't mean to say that a moving collector is impossible, what is
>>>>> impossible is to make allocation a "pointer bump".
>>>> The compiler already passes a TypeInfo on allocations IIRC. And TypeInfo can 
>>>> produce a TypeInfo[], it just happens that DMD and GDC don't fill it in for 
>>>> user-defined aggregates, and LDC needs a compile-time #define to enable it 
>>>> (because it breaks linking the Tango runtime, IIRC).
>>>> (For other types, this fact it returns null is a simple library issue)
>>> Well, this is nice to know (even when it's not used yet, it's better than
>>> nothing). And how can the GC obtain this kind of information?
>> Well, since the allocation routines should all get a TypeInfo reference
>> from the compiler, the GC can store the typeinfo for each memory block
>> somewhere, and later use it. It can then call ti->offTi() which should
>> return an array of OffsetTypeInfo structs (see object.d[i]). The only
>> caveat is that those array return values should be statically allocated;
>> the GC probably won't like an allocation happening during collections...
> 
> But right now gc_malloc() doesn't take any TypeInfo argument. I can't see
> where I can get the TypeInfo in the first place =/

The call would have to be modified.  Right now the best you can do is 
pass BlkAttr.NO_SCAN.  And storing a pointer per block could add a good 
bit of bookkeeping overhead for small objects, of course.  Perhaps the 
TypeInfo array could be converted to a bitmap or some such.