Open Bug 1464157 Opened 6 years ago Updated 2 years ago

Implement the pre-barrier as a builtin thunk

Categories

(Core :: JavaScript: WebAssembly, enhancement, P5)

enhancement

Tracking

()

Tracking Status
firefox62 --- affected

People

(Reporter: bbouvier, Unassigned)

References

Details

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
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
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
Component: JavaScript Engine: JIT → Javascript: Web Assembly
Summary: wasm: Implement the pre-barrier as a builtin thunk → Implement the pre-barrier as a builtin thunk
Priority: P3 → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.