I'm still tinkering with my parallel parse prototype, and I'm planning to try it on a few large scale projects. I'm not currently seeing the perf-gains I would hope, but its too early to say if its an issue with the shared structs functionality, the size of the projects I've been using for testing, or something about how I've had to hack around parts of the compiler to get something functional.
I wrote a rudimentary work-stealing thread pooling mechanism, but I'm finding that adding more threads slows down parse rather than speeding it up for the monorepo I've been using as a test case. CPU profiling shows a lot of the threads aren't processing work efficiently, and are either spinning around trying to steal work or are waiting to be notified of work. Spinning isn't very efficient because there's no spin-wait mechanism nor the ability to write an efficient one (I can sort-of approximate one using Condition.wait with a short timeout to emulate sleep, but I can't efficiently yield). I also can't write efficient lock-free algorithms with shared structs alone, since I can't do CAS, so the fastest "lock-free"-ish updates I can perform are inside of a Mutex.tryLock unless I want to fall back to also sending a SharedArrayBuffer to the worker just so I can use Atomics.compareExchange.

Here's a rough approximation of the thread pool I'm using right now, if anyone has suggestions or feedback: https://gist.github.com/rbuckton/3648f878595ed4e2ff3d52a15baaf6b9

I also can't write efficient lock-free algorithms with shared structs alone, since I can't do CAS, so the fastest "lock-free"-ish updates I can perform are inside of a Mutex.tryLock unless I want to fall back to also sending a SharedArrayBuffer to the worker just so I can use Atomics.compareExchange.

why can't you CAS shared structs?