Allowing instantiation of modules that import linear memory as shared, with unshared memory

Open
#82 8 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
wasm
Domain
compilers

Research direction

No files, tests, or entry points are named. Start by reading the WebAssembly shared-memory import validation and instantiation rules described in the issue, then identify the proposal's relevant specification text and tests. Done means reaching agreement on whether non-shared memories may satisfy shared-memory imports and updating the specification and conformance coverage accordingly.

Written by the indexing model from the issue text.

Description

First a caveat that this isn't really about shared-everything (i.e. GC) but about linear memory; but since the threads proposal went to phase 4 this is the current catch-all place to discuss shared memory.

Currently if you compile a module that imports a shared memory, instantiation will fail if the memory you pass at instantiation time is non-shared. This seems like an unnecessary restriction, since even if the module has already been compiled with real atomics, those atomics should still work fine if executed in a single-threaded context. This is somewhat analogous to the fact that atomics are allowed on nonshared memories (i.e. this could be seen as the "dynamic" version of that existing "static" allowance), and also to the fact that we allow loosening of growth restrictions at instantiation time (e.g. instantiating with a memory with a larger maximum size compared to what the module was compiled for).

The use case here would be when an app doesn't know whether or not it would be executed in an origin-isolated web context that allows SharedArrayBuffer. So it could use the same module, and then instantiate it one way or the other. Because atomics are allowed on non-shared memories already, this can be worked around today by actually modifying the bytes of the module's import section before instantiation but that's obviously hacky and loses the benefits of streaming compilation. So it would be much better just to loosen the restriction in the spec here.
/cc @eyebrowsoffire

Dominant language
WebAssembly
Stars
97
Forks
6
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from WebAssembly/shared-everything-threads

All issues in WebAssembly/shared-everything-threads

Similar issues

More Compilers issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.