Ooveex2C's comments

> Pretty much only gamers want +Clock speeds

I wish. We use a commercial path-tracer that scales very well to many cores, GPUs and entire clusters when it's chewing away at a single fixed scene or animation.

But in interactive mode many scene modifications are bottlenecked on a single or few threads and locks until it gets back into the highly optimized rendering code paths. So a lot of work goes into quickly shutting down as many background threads as possible to benefit from high turbo-boost clocks on Xeon Gold processors so the user doesn't have to wait long and then ramp them back up when it's just rendering the fixed scene.

At least in java the recommended way is to only use GC as safety net for resource management. Print a warning when it's cleaned up due to finalizers (or cleaner-refs since v9) and use scope-based cleaning instead where possible.

The error handling in close is platform specific, so you have to convert the file into a raw fd/handle and then pass it to the appropriate libc methods.

Do wasm -> builtin calls, e.g. DOM methods still call the JS code if JS code has been monkey-patched?

E.g. if userscript replaces the built-in window.fetch() API to modify page behavior will wasm also be intercepted?