Stream: git-wasmtime

Topic: wasmtime / issue #4267 shared memory: allow threads and m...


view this post on Zulip Wasmtime GitHub notifications bot (Jun 13 2022 at 22:23):

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.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 14 2022 at 02:34):

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.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 06 2024 at 18:28):

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