Great technical post, however:

> At Monumental we’ve building robots to automate construction, starting with masonry.

If you thought running to construction jobs was safe, well thanks to Monumental, it soon won't be.

The end goal is to achieve a 10% increase of global unemployment by the latest 2035 and 40% of employers anticipate reducing their workforce where AI can automate tasks by the 2030 deadline according to the WEF 2025 Future of Jobs report. [0]

Worse if earlier.

[0] https://www.weforum.org/publications/the-future-of-jobs-repo...

My first guess would be that this early return is always happening after entering the bugged state. The one cleanup task could get stuck or not cleanup after itself properly.

    // Only one cleanup task is posted at a time.
    if (!HasDirtyJSFinalizationRegistries() || is_finalization_registry_cleanup_task_posted_) {
      return;
    }

https://source.chromium.org/chromium/chromium/src/+/main:v8/...

Hey! I too just filed my first Chromium bug[1]! They changed a behavior that broke opening new windows with tabs, and thus broke my advanced tab search extension Tabasco[2].

I was frankly impressed by the experience. They had me create a minimal extension illustrating the issue and were very quickly able automate a bisection that found its root, a security fix somewhat bluntly resolved. They've supposedly fixed the issue in an upcoming release I await with bated breath.

- [1] https://issues.chromium.org/issues/405283740

- [2] https://chromewebstore.google.com/detail/tabasco-advanced-ta...

>FinalizationRegistry

>Avoid where possible

>Correct use of FinalizationRegistry takes careful thought, and it's best avoided if possible. It's also important to avoid relying on any specific behaviors not guaranteed by the specification. When, how, and whether garbage collection occurs is down to the implementation of any given JavaScript engine. Any behavior you observe in one engine may be different in another engine, in another version of the same engine, or even in a slightly different situation with the same version of the same engine. Garbage collection is a hard problem that JavaScript engine implementers are constantly refining and improving their solutions to.

Kinda tricky API

Hm.. I would honestly try to avoid relying on finalization mechanism of a garbage collector like this. It sounds brittle from the start. Even without the bug, I can imagine you can get into a situation where some unused JS object holds a reference to a giant thing in wasm memory, but engine doesn't run the GC, because it technically doesn't know that, it only sees the little pointer object which seems small.

I think WASM had historically had some problem with freeing memory, so I'd probably rather rely on some pooling or arena with explicit memory size limit (for the whole allocated wasm memory).