1322758 - ProfileGatherer might resolve before all subprocesses have finished gathering

Status: RESOLVED FIXED

(Core :: Gecko Profiler, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

Consider this scenario: Along with the main process, we have 2 content processes, and 1 plugin process.

All processes are profiling, and then the ProfileGatherer is invoked to try to do an async gather.

The ProfileGatherer sends out an observer notification asking "hey, who's going to give me a profile", and the 3 subprocesses respond "I will", giving us a count of 3. Each actor in the parent for those subprocesses is then responsible for doing the necessary messaging to get the profiles sent up to the parent.

So Content Process 1 sends up its profile, and ContentParent goes, "Okay, got my profile", so the ProfileGatherer decrements its internal counter.

Then the Plugin Process sends up its profile, and the ProfileGatherer decrements its internal counter.

We're still waiting for Content Process 2's profile at this point. But while we're waiting, Content Process 1 exits. When it does that, it tells the ProfileGatherer - "Here, hold on to this, since I'm going away" (OOPExitProfile), and then we decrement the counter _again_.

Now the counter is at 0, and ProfileGatherer then requests the profiles from everybody - _even though_ Content Process 2 hasn't yet sent up its profile.

So we miss out on Content Process 2's profile in this scenario. This case is what we're often hitting when dealing with tps regressions for e10s-multi. We should fix this so that we can get some useful profiles here.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1322758 - Stop decrementing ProfileGatherer counter when receiving an exit profile.

For some reason, we were decrementing the ProfileGatherer's mPendingProfiles
when receiving an "exit profile". An exit profile is handed over by a subprocess
parent actor, but in order to have that exit profile, the content process
_must_ have sent it up to the parent already, and that means that the counter
had alreay been decremented on its receipt.

This means that if the subprocess parent actor exited, it'd decrement
the counter twice, which means that we open ourselves up for missing out
on profiles that haven't yet reached the parent.

I can't think of a good reason why we'd want to decrement the counter
when storing an exit profile, so I've just removed that bit.

Review commit: https://reviewboard.mozilla.org/r/97932/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/97932/

Comment 2

[Mike Conley (:mconley) (:⚙️)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=1768d586874c

Comment 3

[Markus Stange [:mstange]]

Comment on attachment 8817700 [details]
Bug 1322758 - Stop decrementing ProfileGatherer counter when receiving an exit profile.

https://reviewboard.mozilla.org/r/97932/#review99526

Your reasoning makes sense.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dc7e50632df1
Stop decrementing ProfileGatherer counter when receiving an exit profile. r=mstange

Comment 5

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/dc7e50632df1