Allow specifying virtual address-space size?

[justinmichaud]

This is similar to #4 but on the implementation side.

If an application only needs, say 16gb of ram, then they could specify that their pointer sizes are 34-bit and an efficient implementation could elide all bounds checks by masking every memory index and mapping guard pages after.

JSC currently does this on 64-bit platforms today, but Memory64 would break this optimization.

This could also potentially enable fast signaling memory on 32-bit platforms today for applications that use less than 2gb of memory.

I am curious to hear from others if this is worthwhile.

[sbc100]

Can't this be done done today by specifying a memory size that is exactly a power of 2? In other words, what can the engine do with "pointers are 34bit" that it can't already do with "memory size is 34bit"?

[titzer]

IIUC @justinmichaud is proposing that pointers be semantically 34-bits (or as declared) and the engine is required to ignore the upper bits of the index.

[sbc100]

Ah.. I think I understand. Let me see if I got this right: specifying that engines are required to ignore the upper bits allows engines to use the masking trick without having to check if the upper bits were set (which they otherwise would be required to do in order to trap in that case)? Is that right?

[justinmichaud]

Yes, exactly @sbc100. I recall that when this memory mode was introduced, it was a very noticeable performance progression, but I am not sure if this is true for other engines too.

[sbc100]

Would this be useful for both wasm32 and wasm64?

Would there be a potential performance hit for engines that don't currently use masking, e.g wasm32 engines that rely only in hardware trapping. Would they then need to inject this new mandatory mask on every load/store?

[justinmichaud]

Yes, unfortunately there would be a mandatory mask if we allow authors to specify masks less than 32 bit. This is not needed for my use case, I was just suggesting it in case any 32-bit platforms found it useful.

[programmerjake]

other cases where masking could be a performance hit -- cpus that are introducing range-checked load/store instructions specifically for wasm32/64.

[justinmichaud]

Do we have an example of that @programmerjake? I do not know of any such cpu proposal today.

[programmerjake]

Do we have an example of that @programmerjake? I do not know of any such cpu proposal today.

yes, beginnings of a proposal for PowerISA: https://bugs.libre-soc.org/show_bug.cgi?id=585

[titzer]

It's worth noting that x86-64 still has the FS and GS segments, but they are only a base; the limit is ignored by all current CPUs. The other segment registers technically still exist but are ignored. They are still in the encoding, though, including the prefixes. A future x86-64 chip could make those usable again. (There are even some Wasm members encouraging Intel to consider this for a future design).

[sbc100]

This doesn't seem like it has a lot of support. It also seems like it could be added by as followup proposal (IIUC it doesn't only relate to 64-bit memories so might make more sense as a separate proposal anyway).

@justinmichaud do you agree with my assessment? Can we mark this as post-mvp or close it out?