1698748 - DummyEvent firing at too high rate both in content and parent processes

Status: RESOLVED DUPLICATE of bug 1741682

(Core :: Gecko Profiler, defect, P2)

Description

[Julien Wajsberg [:julienw]]

I captured this in my dev Firefox:
https://share.firefox.dev/3rR7ZBm

You can see DummyEvent Runnable markers on every processes, at high frequency.

In this profile this is latest nightly on Linux X11, right after updating and rebooting it. But I see this reliably whenever I capture a profile.

Comment 1

[Florian Quèze [:florian]]

The code we are talking about here is https://searchfox.org/mozilla-central/rev/526a5089c61db85d4d43eb0e46edaf1f632e853a/widget/nsBaseAppShell.cpp#274-280

It's been around for a very long time (apparently introduced in 2006 in bug 326273).

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

But does it really use any cpu time. It is after all a dummy runnable created for the appshell?

Comment 3

[Markus Stange [:mstange]]

It seems to be firing at a rate of 1000Hz (once every millisecond). Even if it doesn't take any CPU time, waking up the CPU at that rate surely has some power impact.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

DummyEvent should be dispatched to the main thread if main thread is already doing work in AppShell.
Why was https://searchfox.org/mozilla-central/rev/526a5089c61db85d4d43eb0e46edaf1f632e853a/widget/nsBaseAppShell.cpp#207,268 called.
Or do we have some regression that we end up somehow treating the main thread empty when the callback is called.
Or does the profiler somehow affect to this?

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Something in the profiler is triggering this.
I tested locally by changing the DummyEvent to have a counter how often such runnable runs.
It run never during startup, but immediately when starting the profiler it kept running all the time, I think in all the processes.

Comment 6

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Trying to change the profiler interval, the dummy event was dispatched at the same rate.
Profile, with added "DispatchDummyEventMarker": https://share.firefox.dev/3geJ73j

Looking at the sampled stacks, they're all in PollWrapper.
Wild guess: Could the poll be woken up because of the thread sampler periodically sending signals in order to suspend threads?

Comment 7

[Markus Stange [:mstange]]

I recently was looking at a large (> 100MB) profile JSON which was captured on Linux, and the major contributor to the profile size was the amount of DummyEvent runnable markers.

Comment 8

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

P1->P2, because it's not that critical.
It's annoying, and may cause mild confusion at times when people see these repeated dummy events, but it's not spoiling profiles otherwise.
Also, the solution will probably be complex and/or risky (trying to ignore "spurious" wake-ups, at the risk of ignoring a real wake-up that would happen if the profiler was not running), so it may take time to get it right...

Comment 10

[Julien Wajsberg [:julienw]]

🥳🥳🥳