On Wed, May 19, 2021 at 9:25 AM Floh <[email protected]> wrote: > > This will allow stack overflow to instantly wrap/trap rather than > corrupting static data first. > > This would be perfect IMHO. Why not also do this for optimized builds, are > there performance problems with placing the stack at the bottom of the heap? >
Its a binary size thing. If static data can live at addresses < 65k then any instructions referencing addresses within that data is more compact due to LEB encoding of the `i32.const <address>`. Apparently its enough to make a difference. > On Wednesday, 19 May 2021 at 17:03:18 UTC+2 [email protected] wrote: > >> 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/135251cf-08b6-46d6-a762-2f68629ae1b8n%40googlegroups.com > <https://groups.google.com/d/msgid/emscripten-discuss/135251cf-08b6-46d6-a762-2f68629ae1b8n%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/CAL_va28HyZUAHfBz7R-bs6oATgiVLjOg3wpRt0tJt-xM1zcq7w%40mail.gmail.com.
