1. 11
  1. 6

    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.

    1. 2

      Yeah; after reading the article my takeaways are:

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

      1. 1

        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.

        1. 1

          Pretty sure the only point here is to feed licenses data from the JS GC back into wasm

          1. 1

            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.