Do Bytecode Emission without Allocating Scopes
Categories
(Core :: JavaScript Engine, task, P1)
Tracking
()
People
(Reporter: mgaudet, Assigned: mgaudet)
References
Details
Attachments
(4 files)
Scopes are one of the types allocated during BytecodeEmission that need to be deferred.
Following in the footsteps of Bug 1585718 we need to avoid allocating these Scopes during bytecode emission, leaving them until JSScript::fullyInitFromEmitter (which later can be turned into a main-thread merge step).
Assignee | ||
Comment 1•5 years ago
|
||
Avoids future circular include issues.
Assignee | ||
Comment 2•5 years ago
|
||
Depends on D51909
Assignee | ||
Comment 3•5 years ago
|
||
In preparation for deferring the allocation of Scopes to the end of bytecode
emission, we introduce ScopeProvider, which is a facade class for use within
the BytecodeEmitter. This class allows asking the same set of queries that are
asked of Scopes, but when we defer the allocation of Scopes, we may not choose
to answer the queries with a Scope, instead using a (to be implemented)
ScopeCreationData.
Depends on D51910
Assignee | ||
Comment 4•5 years ago
|
||
Defer the allocation of Scopes by implementing ScopeCreationData and family.
The idea is that we do not reify a GC allocated scope until
JSScript::fullyInitFromEmitter (the goal being to eventually move that onto
main thread).
Depends on D51911
Updated•5 years ago
|
Assignee | ||
Comment 5•5 years ago
|
||
Performance testing shows these changes (combined with those in Bug 1592103) appear to have no impact on our metrics when disabled, and also no impact when enabled
Assignee | ||
Comment 7•5 years ago
|
||
Marking leave open, as only preliminary patches are landing today.
Comment 8•5 years ago
|
||
bugherder |
Comment 10•5 years ago
|
||
bugherder |
Assignee | ||
Updated•5 years ago
|
Description
•