You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
The text was updated successfully, but these errors were encountered:
ghost
changed the title
Suggestion: flag to prevent reallocation of shared memory
Introduce flag to prevent reallocation of shared memory
Jan 6, 2021
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):
With cached memory:
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?
The text was updated successfully, but these errors were encountered: