On Sun, Oct 27, 2013 at 12:20 AM, Ben Kloosterman <[email protected]>wrote:
> On Sun, Oct 27, 2013 at 12:19 PM, Jonathan S. Shapiro <[email protected]>wrote: > >> Segmented stacks aren't really a win in any case. >> >> > Yep , nice idea , too expensive. > > Did they work better with all the Bartok changes to scan the amount of > stack needed ? > I doubt it, because the two issues are pretty well orthogonal. The layout of the stack has relatively little to do with incremental scanning. A chunked stack basically buys you two things: 1. The ability to expand the per-thread stack at need, rather than be limited by a size determined at thread create time (c.f. pthreads) 2. Elimination of one type of heap island by allowing stack segments to be allocated from the same virtual region allocator that allocates everything else. The price is that you either need to probe for possible stack segment overflow on every call (underflow can be handled by a stub), or you need to implement a guard page on each segment and have support from the underlying OS. In Windows, there are already a bunch of very awkward interleavings between the kernel stack and the user stack because of SEH and other misfeatures. I would expect that a segmented stack would interact negatively with these issues. One thing to say here is that assessing performance on this sort of thing is quite difficult. On the one hand, language and runtime designers want their languages to be broadly deployable, so they are reluctant to make design decisions that rely on changes to the existing operating systems. On the other, very few language and runtime designers are also microkernel designers, so even if they are *willing* to rely on OS features, very few have the skill and experience across all of the vertical layering involved to implement the right things in the right places. I say "microkernel" rather than "kernel" because kernel developers, as a rule, wouldn't recognize a fast-path trap if it bit them in the ass, and are generally encumbered by the desire to be compatible with legacy standards (e.g. POSIX), and reluctant to "embrace and extend" without a really good reason. One consequence is that it's very hard to evaluate something like chunked stacks in its own right. It's very easy to imagine that a chunked stack implementation, if backed by the right fast-path support from the supervisor, might work very well. But even if that were so, it's very hard to imagine that conventional operating systems would adopt the fast-path support in order to support those yucky and irrelevant managed languages. :-) shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
