Currently, threads and memory64 don't work together: not all memory64 memories will fit into 4GB so Wasmtime will classify them as dynamic to allow the OS to move them. Shared memories cannot be moved; their base pointer must remain the same throughout their lifetime, so Wasmtime only generates shared memories that are static. When memory64 is enabled, however, a memory could be created with a large enough size that its memory plan would be dynamic. If this happens to be a shared memory, Wasmtime returns an error.
@alexcrichton's proposed fix is to create static memory plans for all shared memories and limit the static memory size to the engine's configuration. At runtime, a threads + memory64 program attempting to use above this limit will fail to memory.grow once the engine-enforced static memory limit is reached, regardless of the memory size specified by the Wasm module.
Currently, threads and memory64 don't work together: not all memory64 memories will fit into 4GB so Wasmtime will classify them as dynamic to allow the OS to move them. Shared memories cannot be moved; their base pointer must remain the same throughout their lifetime, so Wasmtime only generates shared memories that are static. When memory64 is enabled, however, a memory could be created with a large enough size that its memory plan would be dynamic. If this happens to be a shared memory, Wasmtime returns an error.
@alexcrichton's proposed fix is to create static memory plans for all shared memories and limit the static memory size to the engine's configuration. At runtime, a threads + memory64 program attempting to use above this limit will fail to
memory.growonce the engine-enforced static memory limit is reached, regardless of the memory size specified by the Wasm module.