From:  Benjamin Smedberg <benjamin@smedbergs.us>
Date:  27 Jan 2017 23:55:43 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.tech.js-engine.internals
Subject:  

Re: JS engine multithreading

NNTP-Posting-Host:  63.245.214.181

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 
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
>