I was SO excited when I first read this article, as I was at the time implementing shared-global multithreading in a fork of JS Interpreter [1][2] and it was thrilling to think that we might one day have true parallelism in a real JS engine, not just simulated concurrency in our educational toy.

Since then I've often wondered if anyone at Apple was still working on this, or if it was just one of those things (like proper tail call support in V8) that was destined never to see the light of day.

A year or so ago I tried tracking it down again (apparently I'd not bookmarked it at the time) but alas several search engines responded only with a sea of articles about web workers.

Finally, last week I put Gemini on the case and, despite it claiming that it didn't exist and that I must be conflating memories of some other related articles it did correctly identify you as the author, after which it was easy to find the link to the original article on your blog.

Since re-reading it I've been wondering if it might be possible to implement it with help from AI (not having written any C++ since before the turn of the century I don't think I'd be too successful doing it unassisted!), or whether JSC's internals might have drifted too far in the intervening years.

It's delightful that someone else has take a stab at it, and I look forward to seeing where this leads.

Thanks for all the work you did laying the groundwork that made it feasible to even contemplate, then contemplating all tricky details and writing the answers down in the form of such an inspiring article.

[1] https://github.com/NeilFraser/JS-Interpreter [2] https://github.com/google/CodeCity/blob/fa1bd2734b806559ffaf...

In case anyone missed it, this PR is based on that:

> This is an implementation of the design Filip Pizlo published in 2017: "Concurrent JavaScript: It Can Work!".

Years ago I did "multithreaded Javascript" by calling into Rhino (Javascript engine) from multiple threads. Granted, I converted Rhino from JVM to CLR, so it wasn't exactly a stable environment, but it did "work".

It’s certainly possible, but I worry that weird things can happen when doing something as “simple” as defining a property if another thread is messing with the prototype chain. Even thread safe property maps can’t entirely save you because operations that need to go up the prototype chain are not and cannot be atomic.

That's excellent work and a great read, Filip!

Yes, you did. And it's a good design. You even did the GC question justice.

My concern is more in the spirit of "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.". Of course JS being single threaded wasn't a hard constraint. Lift it, and people like you can use the parallelism to do great things.

The problem is that most developers are not you. Shared memory concurrency is foot-artillery (especially if truly parallel). Adding threads to the JS ecosystem is selling W48 nuclear artillery shells at the toy store.

JS's ostensible limitation to a single thread forced users to do what they should have been doing anyway: message-passing, thread-per-core architecture, and actor-ish stuff. People who don't know better reach for shared memory concurrency because it seems like a good way to solve problems, but it's actually a dangerous attractor in idea space. JS engine limitations were accidentally keeping people away from it. Now that they can hear the siren's song of a mutex, they'll run around on the hard problems of parallel programming.

Now, that's not a reason to avoid shipping such a system. It's just not something I would have chosen to implement for the masses.