Is that when running a 32-bit or 64-bit process? According to https://learn.microsoft.com/en-us/windows/win32/procthread/thread-stack-size there is this kind of two-stage reserved vs committed machinery at play on Windows, but it reads like there is no attempt to unboundedly grow, but a hard limit is set at thread startup. In a 64-bit program, my understanding is that setting the reservation to e.g. a hundred megabytes of address range should be possible, and it is only committed over if any local stack frame actually needs it.
On Wed, Jan 18, 2023 at 1:02 PM Floh <flo...@gmail.com> wrote: > > 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 <st...@dekorte.com> 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 s...@google.com wrote: >>> >>>> On Fri, Dec 16, 2022 at 2:46 PM Steve Dekorte <st...@dekorte.com> >>>> 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 s...@google.com 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 emscripten-disc...@googlegroups.com. >>>>> >>>> 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 emscripten-disc...@googlegroups.com. >>> >> 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 emscripten-discuss+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/f4dc650d-4ceb-4ebb-aabf-d875ca2007f2n%40googlegroups.com > <https://groups.google.com/d/msgid/emscripten-discuss/f4dc650d-4ceb-4ebb-aabf-d875ca2007f2n%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 emscripten-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CA%2B6sJ-2jeWnDCp_03F9JSFtFjkRVyFagV5Pen_cO4Z6iWuLabQ%40mail.gmail.com.
