Introduce flag to prevent reallocation of shared memory
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- wasm
- Domain
- operating-systems
Research direction
The issue names no repository files, tests, or implementation entry points; start by reviewing the WebAssembly threads proposal and the shared-memory instantiation examples in the report. Establish whether a module-associated memory cache or flag is within scope, define its lifetime and encapsulation semantics, and document the compatibility and validation criteria before implementation.
Written by the indexing model from the issue text.
Description
Instantiating a module more than once allocates new memory for each instance, what if, instead, there could be a flag that would cause all instances to refer to the same memory?
Instead of them being thread-local memories, they would be "global."
This allows Wasm to remain completely self-contained, encapsulated, and in control of its own memory.
Currently, shared memory is completely useless if not importing host shared memory, but every step in between the module getting its memory, and the host passing it to the module, leaves room for mutation, and unexpected change at runtime, as the host has control over the array buffer too.
Nothing more would need to be changed, it would just change the lifetime of the memory.
This could be implemented as a simple cache associated with the module.
Current loading (JS):
// main.mjs:
const memory = new WebAssembly.Memory({ ..., shared: true });
const {
instance,
module
} = await WebAssembly.instantiateStreaming(..., ...memory...);
const thread = new Worker("./worker.mjs", ...);
worker.postMessage({ memory, module });
// worker.mjs:
... // await .postMessage({ memory, module })
const instance = await WebAssembly.instantiate(module, ...memory...);
With cached memory:
// main.mjs:
const {
instance,
module
} = await WebAssembly.instantiateStreaming(...);
const thread = new Worker("./worker.mjs", ...);
worker.postMessage(module);
// worker.mjs:
... // await .postMessage(memory)
const instance = await WebAssembly.instantiate(module);
In the former example, the WebAssembly module's memory may be corrupted later at the will of the host, breaking encapsulation, but the way that multi-threaded Wasm loading works, it leaves no alternative.
Would this break any of the core motivations/ideas/philosophies behind WebAssembly?
- Dominant language
- WebAssembly
- Stars
- 767
- Forks
- 54
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from WebAssembly/threads
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
WebAssembly/threads#254 ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
WebAssembly/threads#253 · 6 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
WebAssembly/threads#245 · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
WebAssembly/threads#240 ·
-
Branch renaming Open
Difficulty 1/5 Under an hour Newbie friendliness 20/100
WebAssembly/threads#237 ·
All issues in WebAssembly/threads
Similar issues
-
Bug Good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
johnsonjh/emu2-cpm86#61 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
arduino/arduino-app-lab#49 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
zephyrproject-rtos/zephyr#120011 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
ValveSoftware/Proton#10167 ·