Out of bounds trap handling for wasm64 by introducing a pointer type?

[cynecx]

Hi,

I've been doing some reading about WebAssembly and it seems that there hasn't been much discussion about the performance issues with wasm64, where we have 64-bit linear memory indices.

As I understand it now, major implementations introduce guards before loads/stores which introduces isolation and memory safety (for out-of-bounds access). But this also introduces significant runtime costs.

This leads us to an optimization: "Out of Bounds Trap Handling" [0], which significantly reduces runtime costs by only considering the cost of the trap handling.

This basically puts guard pages around the actual wasm heap, however, this assumes wasm32 on 64-bit systems. The downside is that it won't work with 64-bit memory indices (wasm64) on 64-bit systems because there won't be enough virtual addressing space to put guard pages around.

Having that in mind, I was wondering, if we could introduce a custom sized pointer type (lets say 40-bits). This allows us to do the 'Out of Bounds Trap Handling' optimization.

For example, a 40-bit sized pointer type would require ~2048GB (virtual address space) per module

0xffffffffff (UINT40_MAX) + 0xffffffffff (UINT40_MAX) = 0x1fffffffffe (still addressable in 64-bit mode)

So I am wondering if this is actually feasible and considerable to have.

[0] Out of Bounds Trap Handling -
https://docs.google.com/document/d/17y4kxuHFrVxAiuCP_FFtFA2HP5sNPsCD10KEx17Hz6M/mobilebasic

[titzer]

Hello,

Introducing 40 bit pointers would likely introduce the need for 40-bit arithmetic on integers, and that will likely be more costly on today's hardware than the bounds checks. Keep in mind that bounds checking memory accesses has about a 15% runtime performance cost, which is not negligible, but acceptable for many use cases.

I think there are better tricks available to the engine for WASM64. E.g. the engine can allocate a second guard region of > 1TiB and emit one additional memory access to guard[index >> 24] before the normal access of the memory memory[index+base+offset]. The second guard region can be arranged so that any upper bits of the index being set results in an access to an unmapped page in the guard region. I expect that this approach will be as fast or faster than an explicit bounds check, and it will almost definitely be less code. We haven't implemented this, but it's something to keep in mind for WASM64 in the future.

[lukewagner]

(That's a cool idea @titzer)

I also have a hope that, as wasm grows in popularity, chip vendors will eventually bring back some form of segmentation (i.e., the ability to check certain memory accesses against a base/limit for free-ish). That would even help wasm32 by avoiding all the huge virtual address space reservations that can (surprisingly quickly) exhaust available space.