A question on the "guard pages" item in Motivation

[yamt]

https://github.com/WebAssembly/custom-page-sizes/blob/main/proposals/custom-page-sizes/Overview.md#motivation

Allow Wasm to avoid guard pages and large virtual memory reservations for particular memories. This enables a Web app with multiple Wasm memories to better stay within the browser's per-page resource limits while still controlling which memories are "fast" and can have explicit bounds checks elided. Similar benefits exist for applications running within multi-tenant function-as-a-service platforms, where virtual address space is also scarce.

i don't think this item makes sense. if an implementation want to avoid guard pages, it can do so, regardless of page sizes.

if this item is simply about saving memory when you have many memories (with multi-memory and/or multi tenant) i can understand. but "avoid guard pages" in bold made me think it isn't the intention.

[ppenzin]

I personally don't understand why avoiding guard pages is brought up as motivation, as it is seems to be a downside instead. Without guard pages memory accesses has to be explicitly bounds-checked, and this likely would invalidate performance assumptions in environments that currently use them.

[conrad-watt]

I interpret this item as meaning that if an implementation has decided to use guard pages wherever possible and is therefore causing an ambitious user with many modules to run out of virtual memory, this proposal gives the user a new lever to effectively "force" the implementation into using a bounds checking strategy.

I think this point is true and may end up happening in practice, but IMO it's separate from, and less important than, the main motivation of this proposal, which is to allow Wasm modules in environments with <64/128k memory.

[yamt]

I interpret this item as meaning that if an implementation has decided to use guard pages wherever possible and is therefore causing an ambitious user with many modules to run out of virtual memory, this proposal gives the user a new lever to effectively "force" the implementation into using a bounds checking strategy.

your interpretation makes sense. thank you.

I think this point is true and may end up happening in practice, but IMO it's separate from, and less important than, the main motivation of this proposal, which is to allow Wasm modules in environments with <64/128k memory.

listing it as one of three motivations made me think it was something important. i'd suggest to remove it. https://github.com/WebAssembly/custom-page-sizes/pull/16

[fitzgen]

I interpret this item as meaning that if an implementation has decided to use guard pages wherever possible and is therefore causing an ambitious user with many modules to run out of virtual memory, this proposal gives the user a new lever to effectively "force" the implementation into using a bounds checking strategy.

I think this point is true and may end up happening in practice, but IMO it's separate from, and less important than, the main motivation of this proposal, which is to allow Wasm modules in environments with <64/128k memory.

Yep.

i'd suggest to remove it. #16

Makes sense to me.

[fitzgen]

Closing this as #16 is merged now.