juj

> > Would it be possible to somehow make a softer version of WebAssembly.Memory maximum field? > IIUC, this is already permitted by the specification, since even when setting a...

> @juj It seems like, if browsers _did_ implement the FF `maximum`-reservation scheme, then with a 2gb `maximum` specified, there should be no difference in your experiment between (1) the...

> (As a side note on terminology, and I'm not sure if I'm correct here, so happy to have corrections, but, IIUC: "committed" means neither "virtual address space allocated" nor...

> Thus, memory reserved by `maximum` is _necessarily_ pristine/unpopulated, so the browser can unobservably (other than failing a _future_ `memory.grow`) release it. I do understand that, but that is not...

> I would imagine that usual internal fragmentation problems would prevent `memory.shrink` from helping much with `malloc()`+`free()` (e.g., if there is even 1 tiny `malloc()` performed after the large temporary...

> But where is the data written, at what index? The data is copied onto the wasm heap on the line `textArray.set(textLen);` starting at index 0. > How does it...

> the stack while executing code is a separate data structure / concept from a "memory" in wasm > does this assumption still hold when compiling C Essentially yes. In...

> but I am still unsure how emscripten keeps the two (or more) stacks from growing into each other. Emscripten establishes a fixed size linear stack address range for each...

Now with the version number being bumped to 2.0 there is even a greater need to find a succinct documentation about "what does WebAssembly 2.0 contain that WebAssembly MVP did...

Looking at the current code, I am very worried about the potential need of such "helper code". Also while assembling the SSE1 support spreadsheet, I could not imagine how to...