Defining Symbol.dispose and other symbol methods

[guybedford]

With explicit resource management becoming a common pattern in the JS ecosystem, it could be worthwhile to support defining a Symbol.dispose method on custom descriptors to associate custom destructor operations with a given GC object.

Has there been previous discussion of supporting this pattern of resource consumption when working with GC descriptor objects?

There are also other Symbol methods that could be useful to define - Symbol.asyncDispose, Symbol.iterator, Symbol.asyncIterator, Symbol.toStringTag, Symbol.hasInstance and Symbol.toPrimitive (full list - https://tc39.es/ecma262/#sec-well-known-symbols).

A general way to allow these methods could be to support all well known ECMA-262 symbols with either a special bit or a special prefix like @@wellKnownSymbol (the old ecma-262 naming convention for these symbols, new convention is %wellKnownSymbol%). There is then also the question if custom symbols should be supported via Symbol.for('foo'), where that would then need separate design as well. But well-known symbols is likely good enough.

So the main questions seem to be:

• Is Symbol.dispose a use case worth supporting?
• Is supporting all well-known symbols worthwhile, and therefore a general Symbol solution is preferable?
• Should Symbol.for also be supported?

[jakobkummerow]

Manually installing such properties on the respective prototypes can address these use cases, right?

I'm not opposed to thinking about ways to extend the declarative prototype setup mechanism, but I'd like to see some evidence that the manual escape hatch isn't good enough.

[guybedford]

Manually installing such properties on the respective prototypes can address these use cases, right?

Yes exactly. Am I understanding the argument correctly here that well-known symbols are likely only ever a small couple of descriptor cases, so that the proposal goals in supporting a bulk n descriptor optimization are still obtained fine without this case? That argument certainly makes sense if supporting ergonomic JS interop remains a non-goal currently.

[jakobkummerow]

Supporting ergonomic JS interop is absolutely the goal of this proposal.

My argument is that the mechanism that's designed for efficient bulk operations (installing thousands of methods in as few milliseconds as possible) doesn't need to support every last corner case. It was specifically designed to have a manual escape hatch for the cases it doesn't support. We can certainly support more cases with the bulk mechanism, as long as there is some kind of evidence that these cases actually occur frequently. My understanding of Symbol.dispose is that only a very small minority of object types will have such a method, so that seems like a good case to handle with manual setup.

Also, keep in mind that supporting ergonomic interop doesn't mean making Wasm objects support every feature of JS objects. The object models of Wasm and JS are very different for good reasons, and will remain different. It's worthwhile to bridge the gap a bit where it matters; it's a non-goal to strive for full equivalence. If you want JS, use JS.

[guybedford]

Right that makes sense, and this was why I led with the dispose use case. In both wasm-bindgen and Jco, Symbol.dispose is defined on all Wasm-backed objects exposed to JS. At Cloudflare, we have recently found it necessary to implement disposal on request-scoped and DO-scoped objects with a lifecycle unload hook calling this eagerly to avoid monotonic Wasm memory grow increases under less frequent GC resulting in unreasonably high Wasm worker memory allocation. While it can be done with a custom method, Symbol.dispose as the JS standard here helps to avoid using a non-standard convention.

[jakobkummerow]

I don't follow. What does Symbol.dispose have to do with reducing memory consumption? You can't manually free GC'ed objects anyway.
And if you're talking about linear-memory Wasm, then I don't see what that has to do with this proposal.

[guybedford]

Wouldn't GC objects still maintain pointers to linear memory data allocations and/or host buffers? I guess the point is, eager freeing of large buffers that exist in host or linear memory is useful in resource constrained environments.

[jakobkummerow]

It's technically possible to combine GC objects and linear memory, but I don't know of a toolchain that does that.