wasm: Implement the pre-barrier as a builtin thunk

NEW
Unassigned

Status

()

enhancement
P3
normal
11 months ago
4 months ago

People

(Reporter: bbouvier, Unassigned)

Tracking

(Blocks 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox62 affected)

Details

(Reporter)

Description

11 months ago
In bug 1450261, the jit runtime prebarrier is reused and it Just Works. However, time spent under the prebarrier won't show up under the profiler, because we're running under wasm code, then we call the prebarrier stub (that doesn't have profiling info), which may then call into C++. We lose profiling info from the prebarrier stub (included) to the C++ call.

Instead, we could generate a wasm builtin thunk that contains the prebarrier stub + call to C++. It would then have its own exit frame etc. so it would show up in the profiler. It would be nice if we could do this and reuse the code that generates the prebarrier [1]; since it embeds immediate pointers, like the JSRuntime, we'd need to have two ways to load the JSRuntime (as an ImmPtr for the jit, load it from the TlsData for wasm).

[1] https://searchfox.org/mozilla-central/source/js/src/jit/x64/Trampoline-x64.cpp#784

Comment 1

11 months ago
Thanks for filing.  Only recommended tweak is we generate an exit frame (as in GenerateExit(Prologue|Epilogue)) as one of the eager module stubs (i.e., in GenerateStubs()).  Then it can be statically called from all the inline barrier paths.
Priority: -- → P3
Does not block Milestone 1.
No longer blocks: 1444925
(Reporter)

Updated

8 months ago
Blocks: 1488199
There is a subtlety on ARM64, see bug 1489994.  That probably would not have been an issue if we'd fixed this bug, but a very local fix is available for the other one for the time being.
See Also: → 1489994

Updated

4 months ago
Component: JavaScript Engine: JIT → Javascript: Web Assembly
You need to log in before you can comment on or make changes to this bug.