search

WebAssembly / memory64

Memory with 64-bit indexes
Other
194 stars 21 forks source link

Allow specifying virtual address-space size? #28

Closed justinmichaud closed 1 year ago

justinmichaud commented 1 year ago

This is similar to https://github.com/WebAssembly/memory64/issues/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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

justinmichaud commented 1 year ago

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

programmerjake commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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?