Verify that call stacks for inlined functions are correct
Categories
(Core :: JavaScript: WebAssembly, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox135 | --- | fixed |
People
(Reporter: rhunt, Assigned: rhunt)
References
Details
Attachments
(9 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
We should double check that frame iteration and error stack reporting correctly reports the 'source level' call stack, not the 'inlined' call stack.
We can get an error stack with new Error().stack.
| Assignee | ||
Comment 1•2 years ago
|
||
Inlined call stacks are indeed not correct with inlining.
| Assignee | ||
Comment 2•1 year ago
|
||
I'm replacing a usage of Vector with HashMap, and I need the
equivalent of Vector::swap for HashMap.
| Assignee | ||
Comment 3•1 year ago
|
||
CallSite currently is conceptually three fields:
- 'Kind'
- 'BytecodeOffset'
- 'ReturnAddressOffset'
These are bitpacked into 8 bytes by combining the bytecode offset and
kind. However this bitpacking is not truly valid and our static
assert here is wrong. With very large modules (which are very difficult
to write tests of) we could overflow the bytecode offset limit.
In addition, for inlining we will need a CallSite to be able to represent
not just a single bytecode offset but a stack of bytecode offsets for all
of the 'inlined callers'.
Call sites are extremely common, so minimizing space usage is important.
This commit reworks the storage to fix both of these issues with several
changes:
- Switch from using an 'array of structs' to 'struct of arrays' approach
for CallSite storage. The new class is called 'CallSites'.- This allows us to replace the bitpacking with just storing 'Kind' in
a separate vector. The overhead for each call site goes from 8 bytes to
to 9 bytes. If we kept the array of structs, the overhead would have
gone to 12 bytes due to padding.
- This allows us to replace the bitpacking with just storing 'Kind' in
- Add a reference to a stack of bytecode offsets 'inlinedCallerOffsets'
to CallSite.- This is created by RootCompiler which maintains a stack. The stack is
shared for every call site within a function.
- This is created by RootCompiler which maintains a stack. The stack is
- Add a sparse hashmap to CallSites that tracks the 'inlinedCallerOffsets'
for each call site. This reduces storage because many call sites will
not be in an inlined function. For baseline, none of them will be.
The 'inlinedCallerOffsets' data is not used yet. That will require changes
to WasmFrameIter.
Depends on D231455
| Assignee | ||
Comment 4•1 year ago
|
||
Depends on D231456
| Assignee | ||
Comment 5•1 year ago
|
||
The state on WasmFrameIter is difficult to reason about.
- Group the state by 'kind' and note when they are
safe to access. - Add more assertions.
- Reset more state to default values in popFrame.
- Switch from "Mode" to a boolean flag. This helps
when inlining is added as that's another independent
mode.
Depends on D231457
| Assignee | ||
Comment 6•1 year ago
|
||
Add a mode to WasmFrameIter that will read the CallSite data prepared
by the earlier patch and use it. This mode disables access to physical
frame data. This mode is used only by FrameIter which is used when
generating stack traces.
Depends on D231458
| Assignee | ||
Comment 7•1 year ago
|
||
Similar to CallSites in the previous patch, move to a struct of arrays
approach for storing TrapSites. This will also make it easier to have
a sparse inlineCallerOffsets map (in the next patch).
Depends on D231459
| Assignee | ||
Comment 8•1 year ago
|
||
Add a sparse map of inlineCallerOffsets to TrapSites, similar to
CallSites. This map lives on the inner TrapSitesForKind class as
it is indexed by an entry in the vector.
A later patch will use this information and fill it in.
Depends on D231765
| Assignee | ||
Comment 9•1 year ago
|
||
Signal handling looks up a trap and gives that information to the
JitActivation using startWasmTrap. WasmFrameIter then reads that
information. We need to plumb the inlining information all the
way through that.
Depends on D231766
| Assignee | ||
Comment 10•1 year ago
|
||
Update all previous code which just passed around a BytecodeOffset when
identifying a trap to pass around a TrapSiteDesc instead. There are a lot
of users here, but they're all very mechanical.
Depends on D231767
Comment 11•1 year ago
|
||
Comment 12•1 year ago
|
||
Backed out for causing SM bustages.
Backout link: https://hg.mozilla.org/integration/autoland/rev/4dc4b3c1d36a39b285603238e0d622abe45e48da
Failure log:
https://treeherder.mozilla.org/logviewer?job_id=486895817&repo=autoland&lineNumber=20576
https://treeherder.mozilla.org/logviewer?job_id=486901971&repo=autoland&lineNumber=3702
Comment 13•1 year ago
|
||
Comment 14•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/0a51b5c91d67
https://hg.mozilla.org/mozilla-central/rev/899a84b48df0
https://hg.mozilla.org/mozilla-central/rev/bbaa4b84e861
https://hg.mozilla.org/mozilla-central/rev/db490f6445cf
https://hg.mozilla.org/mozilla-central/rev/b52637fa0a96
https://hg.mozilla.org/mozilla-central/rev/8641cf19826f
https://hg.mozilla.org/mozilla-central/rev/cf1c7b54383d
https://hg.mozilla.org/mozilla-central/rev/6046eda1f062
https://hg.mozilla.org/mozilla-central/rev/7913ff2dd3b3
https://hg.mozilla.org/mozilla-central/rev/f23c58fbde51
| Assignee | ||
Updated•1 year ago
|
Description
•