JavaScript is inherently running on a single thread, unless website are making use of workers.

At the moment, SpiderMonkey (Firefox) is capable of parsing JavaScript all functions eagerly before the execution, or on-demand before each function execution.

Parsing every function eagerly has the advantage that the code of the parser remains in the CPU as long as possible. On the other hand, parsing functions on-demand has the advantage that we minimize the time before starting the execution.

However, until recently, SpiderMonkey was only capable of parsing functions on other threads only before the execution of the JavaScript code. As soon as JavaScript started executing, we would only rely on on-demand parsing on the execution thread. This problem got removed with the Huge work from the team to decouple the parser from garbage collector, creating a new intermediate format, and making it capable to execute on-demand parsing on other threads.

By enabling the parsing of functions concurrently, SpiderMonkey is now capable of using other threads to parse each function selectively and eagerly, while the main thread is executing JavaScript code. Doing so yields the same benefit as on-demand parsing, which can execute JavaScript code as soon as possible, with the benefit of moving the on-demand parsing cost to other threads which were previously idle.

A delazification strategy specify how SpiderMonkey/Firefox handles lazy
functions. Lazy functions are function locations which are placeholders for
functions which are left un-parsed after the first iteration over the of
JavaScript code.

Previously, we switched from parsing everything eagerly, to on-demand parsing
and then back to parsing everything eagerly except for inline scripts. Parsing
everything eagerly has the advantage of avoiding switching between the parser
code and the executed code, which yield a better throughput of the generated
code. On the other hand parsing on-demand has the advantage of reducing the
latency before the execution start, at the cost of messing up with the CPU
caches and reserved allocations for the parser. Both are delazification
strategies.

This patch changes our delazification strategy to use a middle ground where we
do parse everything eagerly, as well as reducing the latency before the
execution start. This is accomplished by moving the on-demand parsing tasks to
helper threads, which goals are to visit every function in the source order to
race with the main thread execution of functions, and hopefully succeed at
parsing and generating bytecode ahead of their execution. In the worse case, the
main thread will parse the function without waiting on the helper thread result.

(In reply to Nicolas B. Pierron [:nbp] from comment #1)

Created attachment 9285308 [details]
Bug 1779292 - Select a new default delazification startegy.

Comparing the performance before and after this patch on Try:
https://treeherder.mozilla.org/perfherder/compare?originalProject=try&originalRevision=72615a695e8fc2af3f94387a8daafc8bfbe5daec&newProject=try&newRevision=619cbab55ce2a5fd02d96a61c6d181690218669f&framework=13&page=1&showOnlyComparable=1

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:nbp, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #3)

:nbp, could you have a look please?

This patch is perfect, however it is pending on the results on A/B testing which has not yet started.
I am working on Bug 1779940 in order to avoid on corner cases of our previous on-demand delazification which fails miserably compared to eager delazification.