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•2 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•2 years ago
|
||
Depends on D164333
Assignee | ||
Comment 3•2 years ago
|
||
Depends on D164555
Comment 5•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/343425669f57
https://hg.mozilla.org/mozilla-central/rev/ac0c7c9bbd8e
Description
•