Good question... it's not too long ago that I dropped 32-bit support, so I remember a 32-bit issue. In any case. But I never used the MSVC /STACK linker option with two numbers, so I'm telling it the 'reserve' size (not the 'commit' size), so I guess that means it's not taking up that much physical memory, but when it hits the reserve capacity it's still a stack overflow error?
Well nvm, kinda off-topic for Emscripten :) On Wednesday, 18 January 2023 at 15:50:43 UTC+1 jj wrote: > 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 <[email protected]> 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 <[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 >> >> <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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/270f41e4-62b0-4c29-80e3-3f03acf6e557n%40googlegroups.com.
