This is… pretty half-baked. There’s no mechanism for code in the wasm side to query the liveness of an object, or to contribute liveness from the wasm-side, or to hold weak refs to a JS object, and you should definitely use window.requestIdleCallback() rather than setTimeout() or setInterval()
Weak refs are an invaluable (and non-substitutable) tool for developing robust systems that stay up for long periods, such as line-of-business GUIs, and to leverage the built-in collection machinery for eventing systems that don’t leak without having to know the gory details of who’s listening, but if they’re done poorly you’ll just get a false sense of security and even weirder bugs and edge cases.
I’m going to need a reference counting mechanism inside the WASM vm, and I call refcount_release(ptr) instead of calling the destructor directly.
Let’s wait for FinalizarionRegistry after all.
The idea of polling memory for release sounds fairly wasteful to me. But even a loop over 10,000 objects is probably no time at all compared to any DOM finagling.
Sadly agree that the author didn’t know enough about the topic to really make any case. To pick one example, a weak ref can’t catch cycles, which is one of the basic things a garbage collector does.
That doesn’t make any sense. Weak refs are part of the API of a collector, cycle detection is an implementation detail, and only a thing if you’re reference counting. Mark-and-sweep style collectors don’t need to do it.
This is… pretty half-baked. There’s no mechanism for code in the wasm side to query the liveness of an object, or to contribute liveness from the wasm-side, or to hold weak refs to a JS object, and you should definitely use
window.requestIdleCallback()rather thansetTimeout()orsetInterval()Weak refs are an invaluable (and non-substitutable) tool for developing robust systems that stay up for long periods, such as line-of-business GUIs, and to leverage the built-in collection machinery for eventing systems that don’t leak without having to know the gory details of who’s listening, but if they’re done poorly you’ll just get a false sense of security and even weirder bugs and edge cases.
Yeah; after reading the article my takeaways are:
The idea of polling memory for release sounds fairly wasteful to me. But even a loop over 10,000 objects is probably no time at all compared to any DOM finagling.
Sadly agree that the author didn’t know enough about the topic to really make any case. To pick one example, a weak ref can’t catch cycles, which is one of the basic things a garbage collector does.
Pretty sure the only point here is to feed licenses data from the JS GC back into wasm
That doesn’t make any sense. Weak refs are part of the API of a collector, cycle detection is an implementation detail, and only a thing if you’re reference counting. Mark-and-sweep style collectors don’t need to do it.