I just realized that the immix papers don't mention one of the big advantages to bump allocations: when you are allocating multiple objects in sequence, the limit checks can be consolidated into a single check. It seems to me that this is not true for immix, because the occupancy count on each line makes the consolidation difficult. If things can't be consolidated, that's a pretty significant fast-path overhead. Does anybody know if they are consolidating successfully?
Regarding the stack, there is another issue that I hadn't considered: if we use an immix block of some form for the stack, we can't rely on the collector to zero it in the background. We would have needed to zero reference slots anyway, so it's not like this is a new cost, but the stack-of-objects approach may change how eagerly we need to do that. Actually, I don't think it does, but it needs looking at. In the end, I'm coming to the view that a stack map is likely to be better. The stack-of-objects idea ends up having to build the same data that we need for the stack map; it just evades the hash table lookup to find the map record. If the hash is self-scaling, that shouldn't be a big issue, so at this point I'm leaning away from the stack-of-objects idea. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
