On Windows there's a better way than DWARF or SJLJ to catch exceptions I learned today. (I have no idea what I am talking about, but here goes from what I read...)
Windows uses it's own exception handling mechanism known as SEH. GCC supports SEH on Win64 (and has plans I think later for Win32?) More info in the answer here: http://stackoverflow.com/questions/15670169/what-is-difference-between-sjlj-vs-dwarf-vs-seh/15685229#15685229 and issues here: http://comments.gmane.org/gmane.comp.gcc.help/44153 On Thu, Jul 4, 2013 at 5:33 PM, Patrick Walton <[email protected]> wrote: > On 7/4/13 12:58 PM, Daniel Micay wrote: > >> You can create many threads with fixed stacks, they just start off >> using 4K instead of however much smaller our segmented stacks will be. >> A scheduler will just be more expensive than a regular lightweight >> task. >> >> The 15-100% performance hit from segmented stacks pushes Rust well out >> of the systems language niche. I think it does have to change if Rust >> plans on ever fitting in the niche that C, C++ and D do. >> > > I agree. The sole benefit of segmented stacks on modern OS's that lazily > allocate pages is that, on 32-bit, you can avoid running out of address > space with many tasks. This is counterbalanced by these disadvantages: > > 1. There is no way for the compiler or runtime to know ahead of time how > much stack any given task will need, because this is based on dynamic > control flow. > > 2. The consequence of overshooting (choosing a stack size that is too big) > is that the benefit above is reduced. > > 3. The consequence of undershooting (choosing a stack size that is too > small) is disastrous performance. In the limit, the performance degrades to > something like what many Schemes and SML/NJ do, in that stack frames are > malloc'd from the heap. Except that Scheme and SML/NJ have precise > generational garbage collectors with bump allocators in the nursery, and we > have C malloc(). Furthermore, stack segment allocation is the slow path in > C malloc, because it's in a high storage class. So performance becomes > abysmal in the slow path. Unlike systems like Erlang and Cilk, there is no > way to relocate stack segments in Rust because of unmanaged interior > pointers: Erlang could at least in theory correct its mistakes and keep > stacks contiguous (although I don't know if the implementation does). So > the best we can do is cache and hope for the best--but too much caching > increases memory usage and decreases the benefits of stack segments! > > 4. The benefit above is significantly reduced when calling into C code, > and all solutions to this either hurt the benefit more or significantly > penalize the FFI. > > I think that segmented stacks just don't work. *Relocatable* stacks may > work, but not in Rust. From what I have read, Walter Bright and Rob Pike > agree. > > At this point I'd like to suggest just allowing the user to choose a stack > size on a per-task basis, and failing if the stack size is exceeded. > Basically `__morestack` would turn into `fail`. > > Brian has pointed out to me that, currently, running out of stack has to > abort the whole process, because the DWARF unwinder doesn't consider > `__morestack` a "may-throw" position and as a result the arguments would > leak. There are a number of ways we could fix this, ranging from principled > to hacky. But for now I think aborting on stack exhaustion wouldn't be the > end of the world (although others may disagree). > > Patrick > > ______________________________**_________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> > -- -Thad Thad on Freebase.com <http://www.freebase.com/view/en/thad_guidry> Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
