Closed Bug 1715976 Opened 3 years ago Closed 2 years ago

Compile lazy function off-thread

Categories

(Core :: JavaScript Engine, task, P1)

task

Tracking

()

RESOLVED FIXED
98 Branch
Tracking Status
firefox98 --- fixed

People

(Reporter: nbp, Assigned: nbp)

References

(Blocks 1 open bug)

Details

Attachments

(7 files)

Bug 1715966 should decouple the GC from a fork of CompileLazyFunction, we should use this fork to process some set of lazy function off-main-thread.

The goal being to implement a simple strategy which will compile all inner functions off-thread after the top-level parse is complete. This strategy should be behind a preference which is not enabled by default, but only used when testing.

Severity: -- → N/A
Priority: -- → P2
Depends on: 1721849
Assignee: nobody → nicolas.b.pierron
Status: NEW → ASSIGNED
Priority: P2 → P1
Depends on: 1739679
Depends on: 1741403
Depends on: 1741404
Depends on: 1741405

Previously, we had only 2 modes, either we delazify everything on demand, when
the code is being executed, or we delazify everything ahead when doing the
syntax parsing.

These 2 modes will have to be refined in the future, to reduce the number of
delazified function which are written in the bytecode cache, and to eagerly and
concurrently delazify function out-side the main-thread and out-side the syntax
parsing phase.

This change add a DelazificationOption type to enumerate the various modes
which could be a middle ground between these 2 options, and replaces the
forceFullParse_ flag, as it is a specialized case of the delazification
option.

PinnedUnits uses a stack to register all instances and compress source when the
last one exit. As we are going to delazify/parse on helper threads while the
main thread is running, we need a way to prevent source compression which works
across multiple threads.

This change protect the counter of instance and the pendingCompressed with a
Mutex. Thus allowing concurrent uses of the source across multiple threads.

The RuntimeCache is used to wrap the StencilCache recently added to the Runtime.
This cache is made to be filled concurrently by HelperThread DelazifyTask.

Unfortunately, the RuntimeCache are currently protected as being a
MAinThreadData only. This change allows ParseTask / DelazifyTask to modify the
RuntimeCache, to register new stencils in the cache.

When compiling off-thread, the JSContext provided by the helper threads does not
cary the realm of the main thread which cause the delazification task to be
created.

This patch checks whether we have a realm, or working off-thread, to provide a
dummy counter if we do not know where to report it.

This patch adds delazification on helper threads. This patch is quite convoluted
as it includes all functions used to manipulate the DelazifyTask tasks.

A DelazifyTask is an HelperThread task which uses Parse threads to parse and
generate the bytecode of inner functions concurrently with the execution, and
which are scheduled after the initial parse is completed. DelazifyTask, as
opposed to other HelperThreadTask are tasks which are executed and re-scheduled
as long as inner function remain to be delazified based on the strategy used by
the DelazifyTask, implemented by a DelazifyStrategy.

A DelazifyStrategy is a class which holds ScriptIndex-es to be looked at, and
order them by priority or with a pre-defined order selected by the the
CompileOption.

As DelazifyTask-s are not attached to any object in the main thread, they are
automatically discarded when the source is no longer registered in the
StencilCache, or when the JSRuntime actively wait for the tasks to be collected
before the process shutdown.

This patch adds a function to wait until a single function appears in the
StencilCache and only resumes once it is present.

This patch adds a test case which creates trees of inner functions, using
isInStencilCache to count the number of delazified functions at the time of
execution.

Unfortunately, there is no good way to test the stencil cache as it meant to be
a no-op in terms of execution. Thus, this test case checks that functions are
added to the stencil cache, and waitForStencilCache to make sure when the
cache is filled, then the executed function still works fine.

Pushed by npierron@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/69553dace905
Add DelazificationOption type. r=arai
https://hg.mozilla.org/integration/autoland/rev/2baeeabd0e6e
Convert PinnedUnits to thread-safe alternative. r=arai
https://hg.mozilla.org/integration/autoland/rev/95255227044d
Make RuntimeCaches available for ParseTask / DelazifyTask. r=arai
https://hg.mozilla.org/integration/autoland/rev/6bb1909cc597
Ignore delazification counter when working off-thread. r=arai
https://hg.mozilla.org/integration/autoland/rev/67d0447ded80
Add Delazification helper thread task. r=arai
https://hg.mozilla.org/integration/autoland/rev/ac7c449c235f
Add waitForStencilCache testing function. r=arai
https://hg.mozilla.org/integration/autoland/rev/3adc56a7e604
Add test case for concurrent concurrent delazification. r=arai
Regressions: 1752472
Regressions: 1752454
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: