4 ms·
>... 64bit runtimes can use... Did you mean 32bit?
by jcparkyn 3y ago
>... 64bit runtimes can use...
Did you mean 32bit?
- jsheard 3y agoNo, I mean running 32bit wasm code on a 64bit runtime. The trick is that a 32bit wasm instance can only address up to 4GB of memory, and 64bit hosts give you terabytes of address space to play with, so you can reserve all 4GB of address space up front and incrementally commit the pages as the wasm memory grows. If the wasm code tries to access a page beyond what's been committed it will trigger a hardware exception, so there's no need to perform explicit bounds checking. This only works because the wasm address space is significantly smaller than the hosts address space.
- vlovich123 3y agoYou could do the same with 64-bit by choosing somewhere south of 48-bits of actual address space that you hand out, no?
- jsheard 3y agoThat's one way they could do it, not quite free since they'd have to mask off the high address bits at each load/store, but that's probably cheaper than adding a full branch at every load/store. I think the wasm spec would have to be amended for that to be legal though, currently out-of-bounds memory accesses must throw an exception one way or another, and silently dropping the high bits of addresses may turn an out-of-bounds access into an in-bounds access that doesn't throw.
- vlovich123 3y agoNot sure why. They could just guarantee the allocator never hands out invalid addresses no? If you’re trying to access outside the valid range that’s an out of bounds access because the memory range isn’t mapped. I’m sure I’m missing some nuance though.
- deredede 3y agoThe allocator never hands out invalid addresses, but the wasm code can then try to access out of the bounds of the allocated memory (eg huge array index). The wasm runtime and other browser code runs in the same address space but must stay out of reach of the wasm code.
- jcparkyn 3y agoI see, thanks.