> > > > >> Note that an object with an N bit set resides in thread-local storage; >>> no cross-CPU contention exists for such objects. >>> >> >> ???? So what happens when a reference to that object is passed to another >> thread. >> > > It can't be. Objects in the nursery, by design and requirement, are thread > local until they are "graduated" into the general heap. So the answer to > your question is either that a collection is triggered or that the object > is initially allocated in the general heap. > > You definitely don't want to forward these objects, because you'd have to > do a page invalidate on the nursery region until the forwarding completed. > *Definitely* not a good idea! > > This isn't that unusual - objects allocated from the large object store > (LOS) are also allocated from the general heap. The reason general heap > allocation is avoided is to reduce contention and reference counting. That > doesn't have to be 100% effective to make a huge difference. >
In C# style code or async code its a huge issue eg StartThread ( new Data( currentdata.Member) ) ; , or callback delegates , wait handles etc .. Its not feasible that every time you do you trigger a collection .. So you would need a way for the standard lib at least to allocate it on the general heap. > > >> >> >>> *New Object Allocation* >>> >>> - *Question:* Does nursery allocation always proceed from an >>> initially free block? >>> >>> It doesnt say so .. so it would follow normal allocation a free block >> and a recycled block .. >> > > That's one possibility, but it would make the new object bump allocator > more complex, which seems unfortunate. I tend to suspect that their > strategy for nursery collection has room for improvement. > > I think that a better question (on my part) would have been: does tracing > the nursery always cause the surviving objects in the nursery to be copied > into the general heap? > > My *guess* is that surviving objects are unconditionally moved to the > general heap. If so, *some* of those objects will be very young, which > will lead to heap churn. > My guess is moved to the heap but not copied eg the block moves to the heap ...they explicitly state that copy is much more expensive than a mark sweep of a nursery. So they may just update the counts for objects in the block , if all are 0 return the block to free , if not just add the block to the general heap . which will realize the low % use and copy out the few remaining objects. > If we believe the 10% survival heuristic, it might be worth looking at > hybrid collection strategies in the nursery. So here's the thing: > > - The most recent (youngest) 10% of objects in the nursery are > contiguous, at the top of the allocated region. > - Run mark-copy to evacuate everything *below* that to the general > heap. > - Now either run mark-compact on the 10% or just implement a cyclic > nursery bump allocator. > > The point is to give those infant objects time to die young. Note that we > don't even need to mark-compact them. They're only taking up 10% of the > nursery space in any case, and we can just ignore their internal > fragmentation. > > The counter-argument would be: you'll catch those objects when you run the > decrements on the non-live reference from the nursery to the general heap, > and you'll probably end up returning most of those lines to their > containing block at that point. > > Except that if you implement a deferred dec-buf.... > Other possabilities are 1. a plain old Mark Sweep , on a Nursery will be easy if you have copy support. Like URC you add the header durring the sweep . Objects are swept into a normal RC--Immix heap . Should give great performance but pauses a bit of an issue unless you sweep concurrently with a barirer as discussed 2. Similar to your partial sweep but do it in blocks eg Nursery is N blocks and you configure how many are swept / copied eg 70% ( or 10% for low pauses) . For each block , If low survival < 35% sweep it , if high just move the block to the main heap . After blocks are swept / moved blocka are moved to the front. Should be really good > > This is something that can probably be determined only by experiment. > Yep but i think as you said in the URC thread we are confident in what we can build and while we build the rest wait to see what other research turns up. For now we can just start with simple ref counting . > > >> >> >>> >>> - *Question*: Why isn't partial compaction being used here? I.e. a >>> scheme in which up to *N* lines will be moved to the front of the >>> nursery block, with the effect that the oldest lines trend toward the >>> bottom and can be generationally eliminated? Or is this really what is >>> meant by "compaction"? >>> >>> >> Sounds good and there may be an attractive scheme without any stackmap / >> relocation though obviously this will wasted more memory but they do >> recycle to lines in partial blocks . >> > > If stuff is getting copied to the general heap, you need a stack map in > any case. You said this later. > Yes dont copy ... Nursery blocks after being counted just get moved to the main heap unless all objects are removed .. And the allocater will reuse paritally empty lines .. It will give worse fragmentation but sounds pretty good for an early version so many things to deliver. > > > Then they write something in the paper like "well, we wanted to see how > the thing we were focusing on did without polluting the experiment with > other techniques". Sound like anything you may have seen in the RC-immix > paper? > Yep i saw it both papers in URC " Beltway collectors [12] generalize over classic copying genera- tional collectors by adding incremental collection on independent belts which are analogous to generations. Beltway configurations outperform generational copying collectors,but have not been di- rectly compared to BG-MS[12]. We believe that a generalization of ulterior reference counting as the last belt is a Beltway configu- ration that could perform better than the results here. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
