1642783 - Missing JavaScript stack frames in the profiler when executing in the Interpreter

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect, P2)

Description

[Markus Stange [:mstange]]

When loading https://show.apartposters.com/C4HMrDZ/showroom-3 , some JS code is running on a DOM Worker thread, and it all shows up as time spent in the self-hosted "next" function: https://share.firefox.dev/3eJ5Al1

Comment 1

[Kannan Vijayan [:djvj]]

Markus, is this blocking you, and also is there a reduction of this into some reproducible test case?

Comment 2

[Markus Stange [:mstange]]

It's not blocking me now, but missing JS stack frames in general have the potential to waste time for others.
I don't have a reduction of this, unfortunately.

Comment 3

[Kannan Vijayan [:djvj]]

Does this happen only when running in interpreter-only mode? Or is jitcode running here?

Comment 4

[Markus Stange [:mstange]]

From the profile, it looks like there is jitcode running but it's the interpreter's jit code (Baseline interpreter?). More specifically, if you look at https://share.firefox.dev/2UbIBan , the child nodes of Interpret are unsymbolicated addresses, which usually indicates jit code, and those frames call into functions such as js::jit::FreshenLexicalEnv, js::jit::PushLexicalEnv, js::NativeGetElement.

Comment 5

[Markus Stange [:mstange]]

It is also possible that I misdiagnosed this bug and that all the time really is spent in next. But I'd be curious to learn how that can happen.

Comment 6

[Ted Campbell [:tcampbell]]

My best guess looking at this is that we have a js-generator-function that is running in baseline-interpreter. When we are inside next() we resume the generator and do some stack surgery. We are probably not updating the profiler activation data.

Comment 7

[Ted Campbell [:tcampbell]]

The issue that we don't end up with a frame for the resumed function and it all gets assigned to next() which is the generator resume code. This looks like an issue with interpreter.

This might be solvable with the same approach as when we OSR from C++ to Baseline in the middle of a function. https://searchfox.org/mozilla-central/source/tools/profiler/core/platform.cpp#1631-1639

Comment 8

[Ted Campbell [:tcampbell]]

The hubs code seems to have changed so I don't see the same DOM Worker behavior. I believe the underlying issue here was fixed by the profiler fixups around merging samples so closing this bug.