abrown opened issue #4267:
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.
alexcrichton labeled issue #4267:
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.
alexcrichton closed issue #4267:
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.
Last updated: Nov 22 2024 at 16:03 UTC