Managing JS facade objects with WebAssembly.ReferenceMap

[lars-t-hansen]

@lukewagner and @tschneidereit and I were tossing around some ideas for weak references and finalization in JS, specifically to cover the wasm use case for host bindings where we want to wrap wasm objects (represented as addresses in the linear heap) in JS objects, and perform finalization on the wasm object when the JS object is GC'd.

Since weakrefs and finalization in JS are a can of worms, and since we don't know what we'll need for wasm once we have full GC support for wasm, I put together a simple proposal to cover what I perceive to be the main wasm use case at present.

Writeup here: https://github.com/lars-t-hansen/moz-sandbox/blob/master/refmap/ReferenceMap.md

Probably this proposal can be subsumed by, or be implemented in terms of, a "full" solution for weakrefs and finalization, if/when that appears. Also, the proposal does not extend wasm, only the JS interface to wasm.

Comments welcome, obviously.

[alexp-sssup]

This seems a useful tool to have even outside the scope of Wasm. I think this primitive should be enough to significantly simplify the support for Java WeakRefs and friends in our Java-to-Javascript product (CheerpJ).

[domenic]

I think that, if there is some indirect weak reference exposed via the wasm JavaScript API, it should instead be done in a more direct, ergonomic, and non-wasm-specific fashion, such as https://github.com/tc39/proposal-weakrefs/.

[lars-t-hansen]

@domenic, I too would prefer for JS to have this functionality directly, but:

TC39 has failed to act on finalization for many years already, and the JS proposal currently on the table does not meet the use case for wasm, specifically, the ability to observe gc within a turn (indeed that is specifically excluded by the existing weakref proposal), which wasm will really want for applications that implement their own event loop (workers operating in shared memory).

[domenic]

OK, but I don't think you should expose a fundamental new JS API like this while hiding it under the WebAssembly namespace. If you want to create a JS proposal against TC39's wishes, that's "fine" (assuming your JS engine teams agree); just use another standards body. But it should be done in a generic, low-level manner, instead of hiding the low-level primitive inside of a high-level "reference map".

[littledan]

Would it make sense to close this issue? I guess the current approach is the TC39 WeakRef proposal, rather than WebAssembly.ReferenceMap.

[lars-t-hansen]

Sure.