Open Bug 1683957 Opened 4 years ago Updated 3 years ago

Advance fastShutdownStage to 3 on release

Categories

(Core :: XPCOM, task)

task

Tracking

()

ASSIGNED

People

(Reporter: alexical, Assigned: alexical)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(1 file)

This has been enabled for about 6 months on Nightly. It's about time we push it forward - however, there are a handful of minor things showing up in telemetry which need to be addressed first.

Depends on: 1640266

Historically this stuff had been reviewed by Nathan Froyd - there's not really
a clear replacement in that arena, but please let me know if you can think of
anyone better, Nika.

Anyway, a bit of context: what this pref does is it moves us to a model where,
in the parent process, we simply _exit(0) immediately before xpcom-shutdown.
This, somewhat obviously, reduces the time taken to shutdown. Not so obviously,
it reduces the time taken to shutdown by something like 20-30%, based off of
measurements observed on Nightly.

This has been enabled on Nightly for about 6 months now, and I have not heard
anything of dataloss problems or similar. Additionally, we have telemetry
currently enabled on beta which intercepts file writes and captures the stack
at the time. I have manually pulled down these stacks and categorized them,
and the vast vast majority of them are trivially skippable. If further info
about this is needed, there's a conversation in bug 1623943 detailing some of
this from when we enabled it on Nightly, or I would be happy to answer any
questions you have.

Of the stacks that are not trivially skippable, I would still conclude that
they are skippable enough that I'm not worried. What accounts for these are
atomic file writes and friends - things that are not going to leave firefox
in an unusable state, and could be interrupted anyway, either by a crash or
the user forcibly terminating the browser because it's hanging, or power
going out, etc. The volume of these stacks seems to be around 50 per million
shutdowns observed.

Assignee: nobody → dothayer
Status: NEW → ASSIGNED

Hey! This has been sitting idle for a while. Would it make sense for us to start pushing for rolling out a earlier fastShutdownStage on nightly/beta/release again soon?

Flags: needinfo?(dothayer)

I think it would certainly make sense, and I would love to keep this moving forward. I currently don't have the time to allocate to it, though. I will keep bringing it up, and maybe we can slot in work on it in H2.

Flags: needinfo?(dothayer)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: