Alternative to ThreadLocalFunction

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'.

Start by reading the existing ThreadLocalFunction concept and the proposed DispatchFunction, DispatchTable, and bindToDispatch entry points in the issue. Clarify the JS-API behavior for active tables, rooting, trapping, and thread or realm scope. Done would require an agreed design rather than only the current sketch and alternatives.