[meta] Support progressive compilation of CompilationStencil
Categories
(Core :: JavaScript Engine, task, P2)
Tracking
()
People
(Reporter: tcampbell, Assigned: nbp)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: meta)
SpiderMonkey's JS parser typically performs a syntax-only initial parse, followed by on-demand delazification parses as different JS functions try to run. Currently this means delazification is part of main-thread and cannot be done eagerly. We should instead support taking a CompilationStencil
and allow further compilation to add more bytecode without ever allocating to the GC and running the script.
The intent of syntax-only initial parse is to reduce the latency to first execution by performing required early-error checks and little more. By design, it also saves memory by not generating all bytecode when many JS functions are never executed in a page. The latency saving is largely due to not generating the AST (and saving a lot of allocation/memory traffic as a result) as well as not generating detailed bytecode.
With the progressive-stencil proposal, we would allow making use wait time between when initial stencil is first generated, and when the scripts is actually executed to generate bytecode speculatively. This process would have the same Document-agnostic characteristics of parsing to stencil and could run on any thread. This would generate a vector of stencil-updates that augment the ScriptStencil
with bytecode. Thanks to the design of BaseScript
, there is almost no repeated data.
If at the end of loading, we determine that some of these updates are for functions that were never executed, we can directly discard the data without worrying about generated GC things that may be entrained and hard to collect. As a result, we can try speculating without the original long-lived memory concern we had when syntax parsing was first added.
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Assignee | ||
Updated•3 years ago
|
Description
•