Re: [JS-internals] JS engine multithreading

2017-01-27 Thread Ryan VanderMeulen
On 1/27/2017 12:06 PM, Julian Seward wrote: It would be really good if testing for data races with TSan could be an integral, routine part of this development process. ++! We do have bug 1291954 on file for getting an SM(tsan) job up and running in automation, but it doesn't look like

Re: [JS-internals] JS engine multithreading

2017-01-27 Thread Nick Fitzgerald
What an exciting time! On Fri, Jan 27, 2017 at 7:36 AM, Brian Hackett wrote: > > To help avoid threading bugs during and after this transition, > ​​ > bug > 1325050 also adds a ProtectedData class, which is a template that can > be used on class fields to specify the

[JS-internals] Please use ClassSpec for new bultin-object objects

2017-01-27 Thread Tom Schuster
Hey JS team! Please try to use ClassSpec when adding a new built-in object. This means you don't have to manually define all your properties and methods and instead let the ClassSpec mechanism take care of this. It will also link the prototype and stuff like that, so overall a much nicer system.

Re: [JS-internals] JS engine multithreading

2017-01-27 Thread Ehsan Akhgari
On Fri, Jan 27, 2017 at 3:56 PM, Ehsan Akhgari wrote: > On 2017-01-27 11:24 AM, Brian Hackett wrote: > > On Fri, Jan 27, 2017 at 8:55 AM, Benjamin Smedberg > > wrote: > >> Is there something that explains a little more what gains this will buy >

[JS-internals] JS engine multithreading

2017-01-27 Thread Brian Hackett
Bug 1323066 is moving the JS engine to a model where multiple threads can run JS and otherwise interact with a runtime. Initially, threads running JS will be cooperatively scheduled, so at most one thread is running at once, but the target for bug 1323066 is preemptive multithreading where

Re: [JS-internals] JS engine multithreading

2017-01-27 Thread Benjamin Smedberg
Is there something that explains a little more what gains this will buy us or how it will be used at the DOM level? What will these multiple threads actually be doing, running script from a single webpage? How frequent will locking be, and what will locking overhead do to performance? Will there

Re: [JS-internals] JS engine multithreading

2017-01-27 Thread Boris Zbarsky
On 1/27/17 10:36 AM, Brian Hackett wrote: Any thoughts or comments? Oh, one more thing: will a result of this be that jsids can be used across threads (at least if you appropriately pin them and whatnot)? Right now Gecko has some per-thread jsid tables that duplicate information; it would

Re: [JS-internals] JS engine multithreading

2017-01-27 Thread Brian Hackett
These should be the main places where API clients will need changes: - When creating compartments / zones the zone group to use needs to be specified. - The persistent roots API will need some changes to be threadsafe. - I'm not sure about the details yet, but GC tracing APIs might need changes

Re: [JS-internals] JS engine multithreading

2017-01-27 Thread Boris Zbarsky
On 1/27/17 11:44 AM, Brian Hackett wrote: These per-thread jsid tables are used to accommodate the separate worker runtimes, right? That's correct. then they'll be able to share jsids and separate per-thread tables won't be necessary. Excellent. ;) -Boris

Re: [JS-internals] JS engine multithreading

2017-01-27 Thread Julian Seward
On 27/01/17 16:36, Brian Hackett wrote: > Any thoughts or comments? It would be really good if testing for data races with TSan could be an integral, routine part of this development process. We've seen in the past that after-the-fact race detection and fixing is a slow and difficult process,