JSC should support threads in JS

• Component: JavaScriptCore
• Status: NEW ---

[Filip Pizlo]

This will be so fun.  We will use this as an umbrella for making the VM support threads.  This means:

- It will no longer be necessary to start a different VM if you're on a different thread.
- VM and Heap will become global (one per process) again.
- If the client embedding JSC wishes it, those threads will be able to share objects with each other.

[Asbjørn Ulsberg]

While I'm not opposed to the idea of concurrency in JavaScript, I think the proposed API is archaic and quite frankly; horrible. It looks like the proposed API is heavily influenced by Java and while java.lang.Thread worked okay when it was devised over 20 years ago, it is hardly the best take on concurrency in 2017.

Instead of basing JavaScript's concurrency model on Java's old API with explicit Thread objects, lock objects and complicated signalling mechanisms, a modern look on concurrency would be something more akin to Rust's with object ownership and implicit concurrency built in.

Please take this as a praise of the idea of concurrency in JavaScript, but also a nudge to review the concrete API proposal and base it on a more modern take on concurrency than java.lang.Thread.

[Rhys Cox]

(In reply to Asbjørn Ulsberg from comment #1)
> While I'm not opposed to the idea of concurrency in JavaScript, I think the
> proposed API is archaic and quite frankly; horrible. It looks like the
> proposed API is heavily influenced by Java and while java.lang.Thread worked
> okay when it was devised over 20 years ago, it is hardly the best take on
> concurrency in 2017.
> 
> Instead of basing JavaScript's concurrency model on Java's old API with
> explicit Thread objects, lock objects and complicated signalling mechanisms,
> a modern look on concurrency would be something more akin to Rust's with
> object ownership and implicit concurrency built in.
> 
> Please take this as a praise of the idea of concurrency in JavaScript, but
> also a nudge to review the concrete API proposal and base it on a more
> modern take on concurrency than java.lang.Thread.

Surely this could be done in two phases? Take Promises vs async/await as an example. async/await is interoperable with Promises and async functions return Promises, but the underlying Promise API is still available to use if you'd rather do things at a lower level.

The same approach could be taken for the Thread object, for example marking functions as coroutines, etc, which would implicitly create Threads and locks when invoked.

[pg]

(In reply to Asbjørn Ulsberg from comment #1)
> While I'm not opposed to the idea of concurrency in JavaScript, I think the
> proposed API is archaic and quite frankly; horrible. It looks like the
> proposed API is heavily influenced by Java and while java.lang.Thread worked
> okay when it was devised over 20 years ago, it is hardly the best take on
> concurrency in 2017.
> 
> Instead of basing JavaScript's concurrency model on Java's old API with
> explicit Thread objects, lock objects and complicated signalling mechanisms,
> a modern look on concurrency would be something more akin to Rust's with
> object ownership and implicit concurrency built in.
> 
> Please take this as a praise of the idea of concurrency in JavaScript, but
> also a nudge to review the concrete API proposal and base it on a more
> modern take on concurrency than java.lang.Thread.

From the recent post on the webkit blog...

"Our strawman proposal for concurrent JS is to simply add threads. Threads gets separate stacks but share everything else. Threads are great for our experiment because they are so general. We can imagine implementing many other kinds of concurrent programming models on top of threads. Thus, if we can get our VM to support threads, then we can probably get it to support lots of other concurrent and parallel programming models."

[Filip Pizlo]

(In reply to Asbjørn Ulsberg from comment #1)
> While I'm not opposed to the idea of concurrency in JavaScript, I think the
> proposed API is archaic and quite frankly; horrible. It looks like the
> proposed API is heavily influenced by Java and while java.lang.Thread worked
> okay when it was devised over 20 years ago, it is hardly the best take on
> concurrency in 2017.
> 
> Instead of basing JavaScript's concurrency model on Java's old API with
> explicit Thread objects, lock objects and complicated signalling mechanisms,
> a modern look on concurrency would be something more akin to Rust's with
> object ownership and implicit concurrency built in.
> 
> Please take this as a praise of the idea of concurrency in JavaScript, but
> also a nudge to review the concrete API proposal and base it on a more
> modern take on concurrency than java.lang.Thread.

Religious debates about API is not a great use of bugs.webkit.org.

[Asmithdev]

I have read through this proposal throughly and I feel it is important to voice my concerns as I feel I am fairly qualified to speak on the subject. 

Additionally I would have appreciated if the author of this proposal would have made references to existing work that already allows not only concurrent but true parallel execution of javascript logic, **without** having to modify the underlying execution system.

Atomic operations are not a new thing and I have waited a significant portion of time for them to become mainstream and I have invested the last 3 years of my free time developing and improving my own library Hamsters.js which includes a fully featured thread pool with a proper queue system as well and makes use of the existing WebWorker spec to accomplish this. 

The performance limitations I face in the library today revolve entirely around the lack of main stream support for Atomic Operations, the proposed API seems like an attempt to basically negate the massive amount of effort that has gone into making practical use of the existing WebWorker specification for true concurrent and parallel execution of JavaScript logic. Should this proposal ever come to fruition I fear that not only will it cause a rift in the JavaScript community but it will also cause a huge problem for people like myself who have invested years and countless resources into supporting this functionality using EXISTING language conventions and specs.

I find it somewhat unprofessional that such a lengthy article was written up that never referenced work that already brought this functionality to the language and doesn't require throwing the underlying nature of the language out of the window.

Lastly I think work should be prioritized on finishing Atomic Operations support and making it mainstream so I don't have to deal with passing data around like I do now.

[Filip Pizlo]

(In reply to Asmithdev from comment #5)
> I have read through this proposal throughly and I feel it is important to
> voice my concerns as I feel I am fairly qualified to speak on the subject. 
> 
> Additionally I would have appreciated if the author of this proposal would
> have made references to existing work that already allows not only
> concurrent but true parallel execution of javascript logic, **without**
> having to modify the underlying execution system.
> 
> Atomic operations are not a new thing and I have waited a significant
> portion of time for them to become mainstream and I have invested the last 3
> years of my free time developing and improving my own library Hamsters.js
> which includes a fully featured thread pool with a proper queue system as
> well and makes use of the existing WebWorker spec to accomplish this. 
> 
> The performance limitations I face in the library today revolve entirely
> around the lack of main stream support for Atomic Operations, the proposed
> API seems like an attempt to basically negate the massive amount of effort
> that has gone into making practical use of the existing WebWorker
> specification for true concurrent and parallel execution of JavaScript
> logic. Should this proposal ever come to fruition I fear that not only will
> it cause a rift in the JavaScript community but it will also cause a huge
> problem for people like myself who have invested years and countless
> resources into supporting this functionality using EXISTING language
> conventions and specs.
> 
> I find it somewhat unprofessional that such a lengthy article was written up
> that never referenced work that already brought this functionality to the
> language and doesn't require throwing the underlying nature of the language
> out of the window.
> 
> Lastly I think work should be prioritized on finishing Atomic Operations
> support and making it mainstream so I don't have to deal with passing data
> around like I do now.

If you don’t want to deal with passing data like you do now then it sounds like you want threads. 

This post only cited the most relevant related work.

[Asmithdev]

Perhaps you misunderstood what I was saying as I am already using workers as threads, it would be wise to do more research in how to communicate between workers today. 

Workers are "threads" and they rely on an underlying message passing interface, atomic operations allow for a shares state and locking, the spec has been publicly available for several years and they will allow a reduction in the amount of data that is moved (serialized) between threads.

Not referencing the most popular JavaScript parallel execution library or any of the other ones that are out there seems like an intentional attempt to muddy the waters as to what options are currently available. 

The childish response is unfortunately par for the course with what I anticipated given the previous lack of references to current JavaScript multithreading/concurrent/parallel execution libraries.

I personally have plenty of experience using things like sidekiq as referenced in the pdf linked later in the article and even the developers of sidekiq clearly warn about it's limitations especially with multiple queues.

"I don't recommend having more than a handful of queues. Lots of queues makes for a more complex system and Sidekiq Pro cannot reliably handle multiple queues without polling. M Sidekiq Pro processes polling N queues means O(M*N) operations per second slamming Redis."

I am not sure why this would have been a referenced program in the first place as it doesn't relate to JavaScript at all.

[Asmithdev]

TL;DR: Atomic operations already allow for the use of existing WebWorkers without serializing data between threads.

[JF Bastien]

(In reply to Asmithdev from comment #7)
> Workers are "threads" and they rely on an underlying message passing
> interface, atomic operations allow for a shares state and locking, the spec
> has been publicly available for several years and they will allow a
> reduction in the amount of data that is moved (serialized) between threads.


It sounds like you think we should implement something else first, that’s not already in WebKit? What spec are you talking about, please provide a URL.

[Asmithdev]

I was hoping to edit my last comment to include these links but I think anyone who views this proposal should understand that there is no need to rewrite the wheel to bring this functionality.

https://github.com/austinksmith/Hamsters.js
https://parallel.js.org/
https://keithwhor.github.io/multithread.js/
https://github.com/MichaReiser/parallel.es

These are the 4 (I am aware of) current multi-threading (concurrent) JavaScript execution libraries out there available for public consumption. None of these libraries required making a new spec or changing the underlying nature of the language. 

My argument is that making a new threading spec when it is unnecessary is not the right way to go when the previous WebWorker and Atomic Operation specs haven't been completely made mainstream or even enabled by default with WebKit and will already solve the data passing issues present today.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics

https://developer.mozilla.org/en-US/docs/Web/API/Transferable

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API

The use of the 3 specs above already allow for the completion of a 100% concurrent and parallel execution of JavaScript logic without major communication overhead, currently my library makes use of Transferables as much as possible to minimize this overhead, Atomics will provide a way to pretty much completely eliminate this overhead so there does not seem to be a valid rational for abandoning the 3 I've listed in favor of an entirely new one that will provide little benefit over existing solutions and will introduce major issues and even more complexity to an already complex ecosystem. 

My personal experience is that threading in JavaScript is traditionally seen as sacrilegious, multi-threading and the issues it brings should be abstracted from the common user as most are unable to deal with those issues when they inevitably crop up.

[JF Bastien]

WebKit already supports SharedArrayBuffer (and Atomic). Fil’s proposal is complementary to that feature set. They don’t do the same thing.

[Asmithdev]

I understand, my concern lies in the formation of a new way to do threading in the language that will supersede the existing worker spec that has already struggled to gain mainstream acceptance even with several competing solutions available for free to make it easier to use in the real world. 

I strongly encourage exploring not adding new ways to do threading but making it easier to adopt the current threading model or even incorporate abstracted threaded execution of logic to the end user. If code could be written sequentially but intelligently controlled to scale and be executed (internally) across N threads using things like async/await for sequential control then there wouldn't even be a need for a threading spec being exposed to the end user.

[JF Bastien]

OK so you’re not asking for something else being implemented in WebKit, but for this proposal to be dropped because you think what’s already available is sufficient?

[Asmithdev]

Correct, I think what is already available with the current WebWorker, Atomics, and Transferables / Structured Cloning is more than sufficient to accomplish any form of concurrent and even parallel execution of logic. Another threading spec will only further fracture the ecosystem and delay adoption of threaded JavaScript

[Filip Pizlo]

(In reply to Asmithdev from comment #14)
> Correct, I think what is already available with the current WebWorker,
> Atomics, and Transferables / Structured Cloning is more than sufficient to
> accomplish any form of concurrent and even parallel execution of logic.
> Another threading spec will only further fracture the ecosystem and delay
> adoption of threaded JavaScript

Please file a different bug then.  This bug is not the right place to have this discussion.

[Asmithdev]

Can the same underlying mechanisms that provide the functionality for workers today not be used in the manner described to speed up the javascript core?

[David Catuhe]

Hey any update on this experiment?

I'm trying to get some movement on the W3C front here regarding threading:
https://www.w3.org/2018/12/games-workshop/