chromatic wrote:
Those are short-lived, mostly-garbage headers that we currently can't reclaim without a full stop the world mark and sweep run.
I've wondered for a long time if we're using an incredibly stupid tree-traversal algorithm during the mark phase. But, to look at the problem more abstractly, any tree-traversal algorithm is going to have a cost relative to n, where n is the number of elements in the tree. No matter what traversal algorithm we use, the biggest gain will be reducing the number of elements we traverse in a mark. Which means:
A) Create a short-lived object pool that's marked/swept frequently, and only use it for call signatures, contexts, etc. We can do this right now without implementing full generational GC using the same strategy we use for constant PMCs: call a separate function pmc_new_adonis that allocates from the "fast dying pool". We can also use a function pmc_new_methuselah for objects we know are created at interpreter startup that will live until interpreter death (there's no reason to run GC on those during operation at all). Like constants, we require that all children of adonis or methuselah PMCs must be allocated from the same pool(s). Splitting off adonis and methuselah PMC pools will mean far fewer mark runs on the ordinary GC pools. (Names chosen for illustration purposes.)
B) Create fewer PMCs: Merge CallSignature/Context/RetContinuation/etc. Avoid boxing until absolutely necessary (chromatic's changes to make CallSignature a typed array should have taken care of that for positional arguments, but we still need typed storage for named arguments).
Allison _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
