Jukka, I wonder what you think about making `-Wl,-stack-first` the default for non-optimizing builds? This will allow stack overflow to instantly wrap/trap rather than corrupting static data first. It does mean the opt builds will have a different memory layout, but this doesn't seem particularly different to all the other things that are already different with opt builds. Floh too, any thoughts on that?
On Wed, May 19, 2021 at 4:18 AM Jukka Jylänki <[email protected]> wrote: > +1 for a lower default. 64KB would be fine for me. The rationale for > that is that it should be a good practice for developers to be aware > that the stack length is fixed during runtime. Assuming we do have > good stack checkers enabled by default by now, then we should be very > good here. > > It is good to note that 64KB wasm stack is not the same as a 64KB > native stack, because in wasm, function call stack and > non-struct&non-array arguments are not part of the Emscripten-compiled > stack. So if one has deep nested calls or recursion, that will not > consume the wasm stack. I'd expect that a 64KB Wasm stack will be like > a 128KB native stack, though of course varies on the application. > > Btw, Floh in that code snippet, it would be good to change the > 'vertices' and 'indices' arrays to be 'const' so that the compiler > will have an easy time to avoid placing them on the stack. That would > be excess work if it did, since it would need to memcpy a new memory > block copy every time the function is entered (to prepare for changes > in the values). Instead, when the compiler knows the values will not > be modified, it can retain a single copy of the data in the global > data section, avoiding use of the stack. It might do that already if > it can reason about the values not being modified, but that probably > depends on what the signature of sg_make_buffer() function is. > > Back in 2019 in > https://github.com/emscripten-core/emscripten/pull/10019 I wanted to > reduce it to 512KB as the default, but that was a bit objectionable > then. Hopefully the issues have been resolved now, I'd love to see a > 64KB default stack. > > It would be nice to be conservative by default, and have developers > have to ask to get more, versus by default consuming more, and have > developers need to gain awareness in order to optimize to less. The > latter leads to suboptimal code being distributed on the web (probably > 99% of Emscripten compiled pages out there are running with a 5MB > stack), the first leads to developer either being happy with 64KB > since most really don't use that much, or crashing once, and then > bumping the size (or changing their algorithms to avoid as much of the > stack). Imo having devs crash once to educate is better than > by-default suboptimal code. > > Also a middle ground - "let's be a little suboptimal but not by much" > feels like it could be a worst of both worlds: it causes excess memory > usage on deployed pages still, but still won't probably save devs from > crashing once to learn. So super constrained seems like the nicest > default to me. > > ke 19. toukok. 2021 klo 11.27 Floh ([email protected]) kirjoitti: > > > > My C coding style is a bit stack heavy because it heavily prefers using > the stack instead of heap allocations. > > > > Example: > > > > > https://github.com/floooh/sokol-samples/blob/b7f8968f6dfd223a80b5ce9f50c40c2b79492403/sapp/cube-sapp.c#L19-L105 > > > > 1 MB is quite certainly ok (but might be a problem for code with lots of > recursions?), but I think 64 KByte is asking for trouble ;) > > > > As long as there are clear runtime error messages which indicate stack > overflow I'm fine with any size though, what would suck is random memory > corruption caused by an overflowing stack. > > > > Cheers, > > -Floh. > > On Tuesday, 18 May 2021 at 22:21:01 UTC+2 [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/0ef02392-4a8b-4442-a48c-957570977659n%40googlegroups.com > . > > -- > 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/CA%2B6sJ-0Pd9WYDd95jnXFEONgfySWYUK5vVOCneTyFOo42c6C_Q%40mail.gmail.com > . > -- 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/CAL_va29xhZYBDKbV__4u%2Bi%2BRfte7kMZuy-n%2BNX6AKCQynTx8cA%40mail.gmail.com.
