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

[Leandro Lucarella]

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?

> >What I mean is you can be as precise as you want, but as long as union and
> >void[] is there, there always be "might be a pointer" fields, and cells
> 
> Oh, I hadn't read that part yet when I started typing this post :)

=)

> >pointed by that type of fields should not be moved, ever. So, even after
> >a fresh collection, your heap can be still fragmented. You have to store
> >information about the "holes" and take care of them. This can be very
> >light too (in comparison with the actual allocation algorithm), but it can
> >never be as simple as a "pointer bump" (as requested by David =).
> 
> Well, it may technically be possible to move a heap object right before
> assignment to a union/void[] or passing to C if the compiler calls
> a library function before doing something like that.

Yes, I guess it's technically possible, but again, it needs (AFAIK)
non-trivial compiler changes.

> Then pinned objects could be allocated on a separate part of the heap
> that never gets moved (unless no more references in untyped memory are
> live, maybe?) and allocations could still be a pointer bump in the
> movable part of the heap.

Sure. And what about the non-movable part of the heap ;)
You still have to manage that, you can't simply ignore it. That's what
I meant with this:

> >So technically, you'll always have to deal with memory fragmentation in
> >D (I don't think anyone wants to drop unions and void[] =), and it's true
> >that it can be minimized to almost nothing. But since it's technically
> >possible, you can never get away from the extra complexity for managing
> >those rare cases.

[...]

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

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.


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