Use WeakRefs for JS<->Wasm memory debugging

[RReverser]

Now that WeakRefs are getting available in both Chromium in Firefox, it might be tempting to look at them in context of JS <-> Wasm interactions, particularly, via Embind and WebIDL.

While WeakRefs are not a reliable mechanism to use as a replacement for upcoming Wasm GC integration, and are not available on all platforms yet, I think we could at least use them to help users with debugging memory leaks.

As a particular example, I'd imagine that when code is compiled with ASSERTIONS and WeakRef support is detected in the JS runtime, Emscripten could attach finalisation handlers to Embind / WebIDL objects and say "hey, looks like you forgot to call .destroy() / .delete() on this value at this line of code" when a leak is detected.

This should help to detect and solve a fairly common source of memory leaks in JS<->Wasm code much faster IMO. Thoughts?

[kripken]

Leak detection sounds interesting. There is some existing work here, which I'm not sure how it relates, but it might:

#8474

And two open issues, #9854 and #9820

[RReverser]

#8474 definitely seems relevant - didn't see it before - but it seems to be used to run C++ destructors and only with some explicit opt-in? I'm not sure how to use it, since there is no test in the PR :( cc @wingo

Either way, that code seems like a good foundation that should be relatively easy to reuse for leak detection, and the PR description mentions it as well:

Note, besides cleanup, finalizers are also useful for leak detection. In a test app I was surprised to see how much garbage I was allocating in JS and never cleaning up. We could enhance this support to add a debugging option if someone prefers to not attach finalizers in production, and just use finalizers for leak detection in a debugging environment.

[wingo]

@RReverser I haven't looked recently but that patch attaches destructors unconditionally if FinalizationGroup is available. However in the meantime the proposal changed; we need to update to FinalizationRegistry, and change to have the callback accept a single object instead of an iterator.

For the debugging case, I assume what would need to be done would be to define some kind of USE flag that would make finalizers verbose instead of silent. For ad-hoc usage it may be enough to add a shim around FinalizationRegistry before loading emscripten, or otherwise editing the generated JS.

[RReverser]

However in the meantime the proposal changed; we need to update to FinalizationRegistry, and change to have the callback accept a single object instead of an iterator.

Would you want to make a follow-up PR?

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

[RReverser]

Bump...