> Most native OSes auto-grow the stack in native code. AFAIK "most" excludes Windows though right? As far as I remember Windows gives me a hard crash if I'm overflowing the stack size determined in the linker invocation.
On Tuesday, 17 January 2023 at 12:13:25 UTC+1 jj wrote: > Most native OSes auto-grow the stack in native code. This is "easy" for > them to do because they are able to leverage virtual memory and have a > large address space, where a custom address range for the stack can be > isolated. The way it is done is that the stack is grown in multiples of > hardware pages, and after the end of the currently used stack, the pages > are not mapped, which leads to a page fault being raised when an > application tries to push the stack too much. At that point, the stack is > then automatically grown inside the page fault handler. What this scheme > gives you is that the hardware MMU is effectively then performing the > safety checks in a zero cost manner. > > In wasm we don't have either virtual memory with page fault handler > support, nor a large address space like native programs have. Hence > supporting automatic stack growth would mean adding a costly stack bump > check inside each function. Unfortunately the upcoming wasm64 or virtual > memory plans don't cover this kind of use case either. > > On Sat, Dec 17, 2022 at 1:43 AM Steve Dekorte <[email protected]> wrote: > >> FWIW. the C implementation of my scripting language (Io) does this and it >> worked well. IIRC, it was also used in PL/I. I've ported Io's C Coroutine >> implementation to emscripten fibers and, so far, it seems to work too. I >> should write some tests for this when I get a chance. One killer app of >> small stacks is for servers handling large numbers of sockets. Coroutines >> make this possible without having to implement buggy and inscrutable stack >> machines on top of callback hell. With dynamic stack sizes you get >> scalability without fragility, and without much overhead if the check >> locations are chosen carefully. Io checks the remaining stack size on each >> (Io level) block/method activation. As long as emscripten provided the API, >> developers could judiciously choose where to put the checks in their C code >> if they choose to compile their app with a smaller stack size. Some >> emscripten define for the stack size might be helpful there, if there isn't >> already one. >> >> >> >> On Friday, December 16, 2022 at 3:26:30 PM UTC-8 [email protected] wrote: >> >>> On Fri, Dec 16, 2022 at 2:46 PM Steve Dekorte <[email protected]> wrote: >>> >>>> >>>> How about adding an API like: >>>> >>>> Emscripten_extendStackIfNeeded(callback), which could be inserted >>>> anywhere stack depth might be an issue and would launch another coroutine >>>> if the stack was almost used up, swap to it, and swap back on return or >>>> exception? >>>> >>> >>> Interesting, auto-magic, segmented and growable stacks. I don't know >>> of any platform that does this, but it is an interesting idea. >>> >>> I think it could be a lot harder than at first glance. The >>> biggest problem is that I think it would involve injecting checks >>> everywhere in the wasm binary where SP is set and everywhere it gets >>> restored. Each of those locations would likely also need some kind of >>> extra local state (e.g. previous segment pointer). So maybe not >>> impossible, but certainly not easy or free of runtime code. >>> >>> Luckily, since the execution stack is completely separate and managed by >>> the VM I don't think it would need to involve any kind of coroutine or >>> control flow primitive. >>> >>> >>> >>>> On Tuesday, May 18, 2021 at 1:21:01 PM UTC-7 [email protected] wrote: >>>> >>>>> I have an open PR to reduce the default stack size in emscripten from >>>>> 5Mb to 1Mb, and we are also considering reducing it even furthur >>>>> (possibly >>>>> to 64Kb which is the wasm-ld default, or to 128Kb, which is the musl >>>>> default): https://github.com/emscripten-core/emscripten/pull/14177. >>>>> >>>>> How many folks out there have run into stack limits with the current >>>>> limit of 5Mb? How many folks are worried they would run into limits if >>>>> we >>>>> reduce the default to 1Mb, 128Kb or 64Kb? Would those who feel they >>>>> need >>>>> more stack be OK adding `-sTOTAL_STACK` to their link command to request >>>>> a >>>>> higher limit? (feel free to respond there, or on the issue above). >>>>> >>>>> cheers, >>>>> sam >>>>> >>>> -- >>>> >>> You received this message because you are subscribed to the Google >>>> Groups "emscripten-discuss" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/emscripten-discuss/4444d68e-5d77-448c-9e97-2cf11e8f0e09n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/emscripten-discuss/4444d68e-5d77-448c-9e97-2cf11e8f0e09n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/d3e50a8a-713e-4ac7-abe2-c5ddd781d702n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/emscripten-discuss/d3e50a8a-713e-4ac7-abe2-c5ddd781d702n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/f4dc650d-4ceb-4ebb-aabf-d875ca2007f2n%40googlegroups.com.
