I would asume that objects in the Nursery are all effectively NN they do not have a count yet...there is a area of danger when there is a sweep but this is with a stop the world .. We can improve this stop but it doesnt bother me that much because you can set a very small or zero nursery giving no global pauses. ( only longer allocation / deallocation thread pauses but a critial thread working on pre created data would not be disturbed at all )
You could just go like RC-Immix that references cant be passed to other threads ? The key here is how long objects are in a Nursery . In Rc-Immix we asume its short , but for a traditional Nursery we asume its much longer. Note your comment to my query of this in Rc-Immix .. If the objects passes a reference to another thread while in the Nursery collect or detect this and instead create the object in the main heap.. I think admitting such objects to the main heap is possible in most cases but im not sure if they can always be identified easily. 2 Less than ideal solutions for both - When a ref is passed to another thread , check all such objects for a header and if so collect - Mark such objects with a ThreadShared ( Pinned = false) Attribute which creates it in the main heap with an optional pin. The question i had is why is the pause short .. I can see they have a barrier and the powerpoint slide showed they know heap reference to Nursery but this must be stored in other objects as there is no header... They then just need to count all stack references and references in the Nursery to get the counts before doing a sweep . This will work for small to medium Nurseries but not a huge one but they also state the Nursery starts out as the whole heap.. Ben On Sat, Oct 19, 2013 at 8:57 PM, Jonathan S. Shapiro <[email protected]>wrote: > This morning I realized that I don't understand how an elided header is > possible in the presence of concurrent mutators. Here's the scenario that > bothers me: > > 1. Thread A creates an object O in Nursery A. > 2. Thread A stores reference to O into some tenured object. > 3. Thread B now reads this reference. > 4. Thread B collects, or performs an integrate, causing a change in > the reference count in O > > > Except that thread A hasn't collected, so O is still in the nursery, so it > has no header and therefore no reference count... > > There is a related hazard if the mutator and the collector are allowed to > run concurrently and RC increments are deferred. You can end up with a > deferred increment in thread A's state that names an object in tenured > space that B is attempting to collect. > > > shap > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
