On Mon, Nov 18, 2013 at 12:37 AM, Jonathan S. Shapiro <[email protected]>wrote:
> 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?
>
I think there is a runtime contraint where the runtime presents 1 call to
alloc at a time.
I see no reason why if the runtime/compiler supports it you cant go.
var ptr= tryallocatecontiguious ( size_of_multiple_objects.)
if ( ptr == NULL)
// allocate each object individually
//construct the objects
Though it does add to the inline path.
I think ( i checked but im not 100%) that the occupancy count is done
durring the collect phase (when processing newroots ) . Note the metadata
for lines is located at the start of the Chunk not the block ( i think all
metadata except the object & object GC header is in the chunk and hence a
block is just unmarked objects)
> 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.
>
I take it we cant rely on the collector to do this because collector
threads have immix block for a stack . Immix should do it in the
background but it doesnt.. there is no issue to do it in the allocator.
Worst case you can have cleared and uncleared blocks where you manually
clear it if none have been cleared. This is probably a safer method
because their is no guarantee the collector has even run .
One huge issue is block availability..Normal Rc-Immix cycle is Allocate
all new blocks ,Allocate all recycled blocks , Run Collect. We probably
dont want a stack to use Recycled blocks so we need some sort of reserve
here.. At this point i think you would want to redesign this and
incorporate some sort of New Uncleared Blocks , Cleared Blocks , Recycled
Blocks , EmergencyBlocks ( copy reserve and emergency stack eg for
collector stack) scheme.
>
> 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.
>
There is still some benefit of a uniform block memory model ,that said
Immix blocks are likely allocated from large page chunks on some archs
which is good but stacks need guard pages.
Writing a good self-scaling hash table is not easy..
I kind of like the idea of writing a reference to static meta data
regardless of the method since
- You want the writing to be as fast as possible and the parsing is less
important .
- It has constant time regardless of the amount of variables.
Ben
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
