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

[Leandro Lucarella]

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

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

> >Anyway I think the important thing here is to at least get a precise heap
> >(I would be nice if one could provide type information for the root set
> >too, I guess).
> >For me there's almost no difference between having a non-precise stack and
> >unions/voids[] or having just non-precise unions/voids[]. You have to
> >support non-movable objects anyway, and I guess the stack is small enough
> >to be a non-problem in practice. I think the cost/benefits ratio of having
> >a precise stack doesn't worth the trouble.
> 
> A precise heap would certainly be a nice starting point, but adding precise 
> stack and registers might be a nice improvement over it. Especially for things 
> like the Tango allocating large stack buffers to avoid heap allocs. They're 
> pointerless, but the GC doesn't know that...

A call to gc_addRange() can be done to inform the GC, but of course it
would be really nice if that's not necessary =)

> IIRC there have been some talks on the LLVM mailing list about how to
> emit stack and register maps, so at some point in the future LDC might
> actually support all that...

That's nice. But for now I prefer to target a more general solution (even
when I'm using LDC for the project).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------