Delay the bytecode de-duplication to the instantiation step
Categories
(Core :: JavaScript Engine, task, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox110 | --- | fixed |
People
(Reporter: arai, Assigned: arai)
References
Details
Attachments
(2 files)
Currently SharedImmutableScriptData::shareScriptData happens inside BytecodeEmitter::intoScriptStencil, but this operation uses per-runtime storage JSRuntime::scriptDataTable_.
In order to decouple frontend from JSContext/JSRuntime, while keeping the cache "per-runtime", this operation needs to be moved to instantiation step.
The downside of this change are:
- the duplicated data is kept until instantiate
- if single stencil is instantiated multiple times, the de-duplication operation will be performed for each instantiation
Comment 1•3 years ago
|
||
Unfortunately, the lock for the scriptDataTable is slightly complicated to avoid needing to take a lock on main-thread when no off-thread parse is in flight. https://searchfox.org/mozilla-central/rev/2d24d893669ad0fe8d76b0427b25369d35fcc19b/js/src/vm/Runtime.h#624-632 . You'll probably have to just try it out and measure performance impact like you suggested.
My guess is that the data size isn't likely a problem. Some mitigations we could do are when we do first instantiate, we can deduplicate in-place in the stencil so that if the stencil lives longer it doesn't waste space. Although that may be complex if a stencil is shared with Workers. It is probably possible to do a per-compilation de-duplication that catches small functions that are likelier to share code.
Computing the HashNumber off-thread might also be useful. It may even make sense to save it in ImmutableScriptData.
| Assignee | ||
Comment 2•3 years ago
|
||
Depends on D164333
| Assignee | ||
Comment 3•3 years ago
|
||
Depends on D164555
Comment 5•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/343425669f57
https://hg.mozilla.org/mozilla-central/rev/ac0c7c9bbd8e
Description
•