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
