Alternative to ThreadLocalFunction

[eqrion]

Apologies for adding yet another idea to consider, but wanted to have it written up somewhere. This came from some discussions with Luke (cc @lukewagner) on how shared wasm functions could call unshared functions without strong shared to unshared GC edges.

The idea is to avoid having the 'unshared function wrapper' that shared wasm calls from being the thing that roots the unshared function, but instead have it be rooted by having the unshared entry point into shared wasm root it.

Here's a sketch:

// ### Instantiation thread ###

// Create a 'dispatch function' which is a shared wasm function that when called invokes
// a corresponding unshared function bound in the active dispatch table.
let dispatchConsoleLog = new DispatchFunction({params: [] results: []});
assert(dispatchConsoleLog instanceof WebAssembly.Function === true);
assert(dispatchConsoleLog.type().shared === true);

// Instantiate a module that imports the dispatch function
let mod = wasmTextToBinary(`(module
  (func shared (import "dispatchFuncs" "dispatchConsoleLog") $dispatchConsoleLog)
  (func shared (export "sharedRun") call $dispatchConsoleLog)
)`);
let instance = new WebAssembly.Instance(mod, {"dispatchFuncs": {dispatchConsoleLog}});
postMessage(instance.exports.sharedRun);

// ### Execution thread ###

// sharedRun() would trap during call to imported dispatch function
// as there is no dispatch table active.
assertTrap(() => sharedRun());

// A dispatch table is specific to a thread (or maybe realm)
let dispatch = new DispatchTable();

// Create a permanent mapping from dispatch function to unshared function
dispatch.bind(dispatchConsoleLog, console.log);

// Need to bind shared functions to a specific dispatch table, resulting
// in an unshared function.
let unsharedRun = sharedRun.bindToDispatch(dispatch);
unsharedRun();
assert(unsharedRun instanceof WebAssembly.Function === true);
assert(unsharedRun.type().shared === false);

DispatchTable acts as a map from shared DispatchFunction pointer to unshared function. Entries can only be added, not removed. To free a mapping, you'd let the whole DispatchTable become collected.

A shared DispatchFunction doesn't keep alive any unshared functions, it basically is just a key to a DispatchTable. The unshared DispatchTable is what keeps the unshared functions alive on each thread. This avoids the need for web engines to do global marking of cross-thread JS and C++ heaps.

We'd modify the JS-API to track an 'active' dispatch table that can be set by through entering a 'bindToDispatch()' function. When a DispatchFunction is called, it does a lookup in the active table for what it has been bound to, then invokes that.

The API is similar to ThreadLocalFunction (which also has the notion of each thread binding the unshared wrapper to that thread's unshared function). The one difference is that every thread must activate a dispatch table before entering the shared code. I think with bindToDispatch (and other similar possibilities), this could be ergonomic.

One useful thing here for the case of emscripten with dlopen and multithreading is that all the modules could use the same dispatch table, so you wouldn't need to switch between tables on every cross-module indirect call. The keys to the table are pointers, so there's no chance of accidental collisions, and new entries can be added over an execution.

There are some details that could be tweaked while maintaining the core idea. Instead of using a 'DispatchFunction' as a key, we could create a "wasm:dispatch-function" import namespace where the string fields in that act as the key to the dispatch table. We could also investigate other ways of maintaining the active dispatch table instead of a 'bindToDispatch'.

[tlively]

Nice, IIUC, the idea is basically to wrap the "use a table index instead of a direct reference" pattern with an ergonomic JS API such that the Wasm still gets to import JS functions as normal-looking shared functions that can be called normally from other shared functions.

cc @syg

[conrad-watt]

To make this work with shared-suspendable, I think you'd need a semantics where after suspending and resuming, you see the parent context's active DispatchTable rather than the one you originally started with. So I see this as essentially a special case of context locals where the only thing you can have in the context is a map from DispatchFunction to JS function that you dynamically check membership of when you want to do a JS call. So in turn I think this ends up looking like a special case of @rossberg's suggestion to make context access dynamically checked - do we feel ready to seriously consider this as a potential solution?