dysfun@treehouse.systems ("gaytabase") wrote:
littlegem: i have been thinking about heap layout with immix-style heaps. you know how most heaps put the header just before the value? turns out when you think about it, this is just a size optimisation that doesnt pessimise every allocation to the minimum size over putting them all in an array.
why? because if we're to avoid an inline header, we need a predictable place to find the metadata for a given pointer, which means one header per minimum object size, even though some objects might be larger than that. and turns out this gets quite large.
alternatives that still uses a predictable layout:
- fixed number of slots smaller than the worst case
- for each line, an index of the slot for the first object in the line. there are only 256 lines per 32kb block, so this is a much more manageable size)
this seems to have some difficulties associated, such as what to do when a block isn't full but has run out of object slots. perhaps we can make the block metadata external and put a pointer somewhere?
immix advertises "0.8% overhead" while having the audacity to talk about correct accounting and ignoring the size of the per-object headers entirely. this is not helpful for trying to work out what is a reasonable gc overhead actually. and since we're already on to a loss on memory efficiency by using a gc at all, it would be nice to bound it better