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

[Frits van Bommel]

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 =/

Ah, you're right. But if you'll look at your nearest lifetime.d[1] you'll see 
that all the allocation routines called by the compiler *do* provide a TypeInfo, 
so apparently it's just not propagated to gc_*. So I guess the first thing to do 
would be to either
   (a) change the signature of gc_{malloc,calloc,extend}()
or
   (b) add something like gc_settype(void*, TypeInfo)...


[1]: Tango name, and presumably druntime as well; I think it's spread all over 
the place for Phobos 1.

>>>> I have no idea how efficient this would be, however. My guess would be
>>>> not very.
>>> I'm not concerned about efficiency, I'm more concerned in non-trivial
>>> compiler changes.
>> Well, efficiency is important too.
> 
> Sure, and it's really hard to assume how efficient that could it be (you
> loose some efficiency in some cases but you probably gain a lot in other
> cases if most allocations are a pointer bump). What I meant is that I can
> test efficiency, to see if this is really viable or not, but it's very
> hard for me to change the compiler (and it's much harder that those
> changes would be accepted in "upstream", and one of my thesis goals is to
> make something useful, that can be easily adopted, not just an academic
> curiosity =).

Well, if it turns out to be a win, I'm sure we could put it into LDC. DMD would 
be up to Walter.