On Mon, Nov 11, 2013 at 9:42 PM, Ben Kloosterman <[email protected]> wrote: > There is some cost however, if you could have any 2^N size then there is far > less point in copying , yet i agree it should not be an issue ... which is > interesting..
I'm not being clear enough about the 2^k thing. When you are running a bump allocator *from the mutator*, you really want to know the size of the block at static compile time (alternatively: at JIT time). This is true because you need to know what mask to apply to the bump pointer in order to find the front of the block. You need that to update the reference count, and you *really* don't want to be doing a table lookup for it. So what this means in practice is that the size of any immix block *in the nursery* really wants to be fixed. I guess in a JIT system you could change it on the fly if you are wiling to flush the existing translation cache. You *do* know at static compile time whether you are stack allocating or heap allocating, so there is no need for those two sizes to match, but it sure helps if the stack is 2^k pages. On some architectures this is desirable in order to find the thread-local data pointer in any case. But in both cases, the need to know the block size statically seems like an impediment to some of the things you were talking about. Relocating objects is another matter. I don't have any experience to draw from on that, but my intuition is that a block-size lookup operation isn't prohibitive there. The bigger issue is that you have now partitioned the blocks by size, and a free block can no longer go naively onto a queue of available free blocks. So I think that there are three "core" block sizes: the one for the nursery, the one for the heap, and the one for the stack. My guess is that block sizes in LOS need to be viewed as a separate problem, if only because they don't satisfy the 2^k property. I do *not* think that the size of the block changes the argument for copying one way or the other. 10% or so of objects in a "young" tenured block will turn out to be long lived, regardless of the size of the block. The question, I suppose, would be the spacial distribution of those islands within the block. I don't think that "splitting" such a block really helps, since the bump allocator is already prepared to skip past such islands. > - It doesn’t have the low cache1 hit rate of sized order heaps because > different sized objects ( related / similar liveliness) are still allocated > adjacent as normal. Up to some new, potentially larger size. Yes. But it's an open question how important that would be in practice. Given what we know about object size demographics, I'm dubious about how much difference it makes. Still, it seems like an easy thing to test and measure. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
