One thing worth noting is a lot of papers use per thread allocators which give better performance in situations with lots of concurrent allocating threads. Hence they use small nurseries that fit in the cores L2. This we know.
However with a hybrid model the cost of using the main heap is much greater than with a generational GC due to introducing ref counting especially ref counting on short lived objects many of which may not have been counted and allowing cycles which may not have escaped a larger nursery. The URC paper found best performance at very large nurseries ( 4 Meg was pretty big for a Nursery 10-12 years ago) but such big nurseries per thread scaled to today uses a lot of memory. Hence an interlocked single nursery may be more memory efficient and avoid synch issues. Ben On Sun, Oct 20, 2013 at 3:39 AM, Jonathan S. Shapiro <[email protected]>wrote: > On Sat, Oct 19, 2013 at 10:53 AM, Bennie Kloosteman <[email protected]>wrote: > >> 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." >> > > Ah. Then I feel a bit better, because it's my mistake rather than theirs. > No contention exists for allocation purposes, but I'm now convinced that > references *can* leak across nurseries. In RC-immix, this isn't an issue > because mutators and collectors are not permitted to overlap. This allows > objects to be relocated cleanly. > > >> >>> >>>> 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 ? >> > > Correct. But I've now moved on to asking "what breaks if we *don't* halt > the world, and how loose can we make the coordination without losing any > key invariants?" > > >> >>> 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). >> > > Getting rid of the pause from the tenured heap is not that big a > challenge. The challenge is to make sure that a short pause for *my* nursery > doesn't require *your* thread to stop. > > >> ...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 disagree. I agree that we don't have to *implement* the world's > fanciest concurrent collector right now. But we need to know that such a > collector is *possible*. > > >>> 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. >> > > It can be backed by playing games in the object locking code. The problem > is that you can't add this attribute retroactively to existing languages. > > > 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
