Optimize stack map finding during tracing
Categories
(Core :: JavaScript: WebAssembly, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox138 | --- | fixed |
People
(Reporter: rhunt, Assigned: jpages)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
wasm::StackMaps is a sorted list and we do a binary search to find a stack map for each call frame when tracing roots. This can be expensive for large modules. We should consider using a hash map for this. I did see this showing up in barista3 profiles back in Feb of this year.
| Reporter | ||
Updated•1 year ago
|
| Reporter | ||
Updated•1 year ago
|
| Reporter | ||
Updated•1 year ago
|
| Assignee | ||
Comment 1•11 months ago
|
||
Metadata used offsets to the beginning of code segment. Change that to use
offsets relative to the beginning of CodeBlock. This allows us to avoid offseting
metadata later on and prepare the work for simplification of stackmaps.
| Assignee | ||
Comment 2•11 months ago
|
||
Wasm stackmaps were stored in a sorted vector and traced at runtime with multiple
binary searches. Using hashmaps should reduce the complexity of iterating over stackmaps.
Updated•10 months ago
|
Updated•10 months ago
|
Comment 4•9 months ago
•
|
||
Backed out for causing bustages complaining about ComputeCodeOffset.
Backout link: https://hg.mozilla.org/integration/autoland/rev/6db7ad98b50985f4cc72770d0104b01263e6a735
Failure log:
https://treeherder.mozilla.org/logviewer?job_id=496096679&repo=autoland&lineNumber=17180
https://treeherder.mozilla.org/logviewer?job_id=496096726&repo=autoland&lineNumber=40716
Updated•9 months ago
|
| Assignee | ||
Updated•9 months ago
|
| Assignee | ||
Comment 5•9 months ago
|
||
I'll land the patch again after the code freeze, ending on March 3.
Comment 7•9 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/1a3bc285395f
https://hg.mozilla.org/mozilla-central/rev/bd2b8b0c2f35
https://hg.mozilla.org/mozilla-central/rev/24eb5e44d488
Description
•