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 ever be shared access to JS object/object graph that requires thread locking? --BDS On Fri, Jan 27, 2017 at 10:36 AM, Brian Hackett <bhackett1...@gmail.com> wrote: > 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 different threads can run JS simultaneously. A > "zone group" abstraction is being introduced, which is a set of zones > and some other data. A zone group may only be accessed by a single > thread at a time, though over its lifetime multiple threads might > access it at different times. There will be roughly one zone group > per tab. > > Doing this requires some pretty significant structural changes to the > core structures in the engine. To reduce churn while work on bug > 1323066 goes on, most of these structural changes are going into bug > 1325050, which shuffles fields around but retains the restriction that > only one specific thread can run JS in the runtime. This bug sets up > the following roles for each of the main classes: > > - JSContext contains all data pertaining to a single thread's state. > Each thread will have a single JSContext which contains its activation > information, other TLS like information about Auto* classes on the > stack, and its current compartment/zone. The context for the current > thread can be obtained with the TlsContext TLS variable. > ExclusiveContext and PerThreadData have both been removed and folded > into JSContext. > > - ZoneGroup contains the data for a zone group described above. > ZoneGroup has a JSContext* field specifying the thread which currently > has exclusive access to its contents. > > - JSRuntime may be accessed by multiple threads. Once we have > preemptive multithreading all the contents of this structure will need > some form of synchronization. Later on we should be able to use the > main runtime for DOM workers, in which case we'll have a single > runtime in the process and the option of dissolving its members into > static variables. > > 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 conditions under which the > field may be accessed. This condition will be checked in debug > builds. Bug 1325050 uses ProtectedData for all the contents of > JSContext, JSRuntime, Zone, and ZoneGroup (and classes embedded within > these), and it would be nice if people could continue to use this for > new members in these classes going forward. (Eventually there might > be an analysis to check that ProtectedData is used on all members of > these classes.) > > Any thoughts or comments? > > Brian > _______________________________________________ > dev-tech-js-engine-internals mailing list > dev-tech-js-engine-internals@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals > _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
