Proposal of Multithread JavaScript

/#!/JoePea joe at trusktr.io
Mon Mar 13 02:11:30 UTC 2017


Leo's idea that JavaScript code as it is today won't be impacted when async
functions are run in separate threads is interesting. It would complicate
the JS engine implementation so that locks are needed when different scopes
access a variable (something which was formally easily safe due to running
on a single thread and now needs to be guarded on multiple threads), but in
theory, multiple threads for async functions that don't need guards against
each other (detectable with more intricate scope analysis) could be an
interesting performance boost.

Suppose the following async function does a cpu-intensive calculation. It
would be nice to be able to do this without workers:

```js
async function somethingIntensive(input) {
  // in new thread, automatically because this function isn't touching
outer scope.
  // ... some cryptographic calculation using input ...
  return result
}

// main thread)
somethingIntensive().then(result => {console.log(result)})
```

Maybe the `await`keyword didn't even have to be used inside the async
function, but just having the `async` keyword makes it possible for the
engine to make a thread if it determines it can do so.

This is a good idea. There's no reason an async function needs to be on the
same thread if it doesn't have to be. Maybe there can be heuristics, like
"hmmm, this function doesn't touch absolutely anything in the outer scope,
and the `input` is a primitive non-object value so we don't even need to
guard anything... let's run it in a new thread".

Or, maybe there can be a new keyword for this specifically if people want
it to be explicit:

```js
thread function somethingIntense(input) {...}
```

The engine could automatically guard stuff in certain ways that would need
to be spec'd out. So, in some cases, threading would be useless if the
function needs to access stuff from outer scope, and the engine might even
be able to *not* run the function in a separate thread if that makes
guarding easier.



*/#!/*JoePea

On Fri, Nov 4, 2016 at 5:42 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 11/4/16 3:16 AM, doodad-js Admin wrote:
>
>> Using threads and shared objects, IPC and serialization/deserialization
>> of objects will no longer be required.
>>
>
> Just so we're clear, what _will_ be required, in the VM, is locking around
> property access and a GC that can deal with multiple threads, right?
>
> SpiderMonkey used to have all that.  We removed it because the performance
> penalties it imposed were not acceptable.  Reintroducing it would be a
> pretty hard sell, for that same reason.
>
> -Boris
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170312/8a176f4f/attachment.html>


More information about the es-discuss mailing list