On Thursday 09 September 2010 16:31:31 Luca Barbieri wrote: > I think I understand: since you reparent everything to the new root > and then call talloc_free on the old root, everything dies anyway > whatever its parent was.
Yeah, that's the idea. All of the IR originally starts out as a child of the (temporary) parse state. We walk the tree and reparent/steal all the live IR once compilation is done, leaving only dead IR (and other temporary junk) as children (or at least descendents) of state. So when we free state, all of that goes away. > However, this makes me think that a copying garbage collection scheme > would be more efficient, since you already have support for visiting > everything alive and are not really using any hierarchical ownership > features, at least for the IR proper. Could be. We'd originally considered writing something like that, but concluded that talloc would do everything we need, already existed, and was well tested. With minimal effort on our part, we could properly free all of our memory...and down the road, begin freeing certain pieces earlier, incrementally improving our memory usage. Also, Carl (and I think Eric) already had experience using talloc. Overall, it's been really nice to work with. > BTW, are you sure that talloc actually works as expected? > Clearly, you can't have an allocator that both allocates by just > incrementing a pointer, can free memory without fragmentation, and > never copies the objects. Right. > However it seems that's the way talloc is being expected to work, > which is impossible: I guess it might not actually manage to free > memory, because "stealing" does not copy objects and they thus keep > alive the old pool, which results in talloc_free() not freeing nothing > or less than it should. I haven't checked though. If you use create a talloc pool, and allocate out of that, then yes - but we aren't doing that. Normally, each talloc'd block is just a normal malloc'd block with an extra header (stored just before the returned pointer) with accounting info. It's essentially like using malloc/free by hand, with a small amount of overhead...in exchange for massively simpler code. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
