On Sat, Oct 19, 2013 at 11:51 PM, Jonathan S. Shapiro <[email protected]>wrote:
> On Sat, Oct 19, 2013 at 7:36 AM, Bennie Kloosteman <[email protected]>wrote: > >> You could just go like RC-Immix that references cant be passed to other >> threads ? >> > > Where do they say that? I'm pretty convinced that it can't be enforced > without a read barrier of some sort, and they make no mention of having one. > You said it unless i misunderstood "Note that an object with an N bit set resides in thread-local storage; no cross-CPU contention exists for such objects." > >> The key here is how long objects are in a Nursery. >> > > Nope. You can construct cross-nursery references even if the nursery only > holds a single object. It may take longer for the race to emerge, but it's > possible. > If there is no count in the Nursery and a stop the world for the count & sweep then how can a race emerge ? > The problem here, really, is to avoid the need for any sort of > all-mutators halt. Even if that halt is just to clear the nurseries > together, the need to synchronize the halt is not happy-making. > Yes thats the problem but why do we care ? 90% of apps just set a big Nursery and who cares about the global pause . For the remaining 10% set a small ( or no) nursery so the pause is tiny ( or better yet partial sweeps as you mentioned so new objects can die) . no pauses with a significant penalty is ok. From this point many optomizations are possible but we dont need to go further until much later in the development , things change and we will have a better handle on the issues with the collector . I think trying to design a FAST concurent / pauseless GC is premature .. First we need a GC perios . Then we need a fast GC with pauses and an average performing one with small global pauses , 20 % diffirence is acceptable as the user chooses the trade off. Once everything is built we can do better there will be more research , we will understand the GC better and now how the rest of the runtime relates. > I toyed with the possibility that objects might only be allowed to pass > between threads through some form of cross-thread stream object, which > would give us a place to stand to do whatever we need. Unfortunately I > don't think that works in practice, because objects live in shared memory. > What about the attribute on such shared objects to avoid nursery allocation entirely. Its ugly and if a user forgets its pretty bad. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
