1878993 - Firefox should signal the Application Launch Prefetcher cache

Status: REOPENED

(Core :: Widget: Win32, enhancement, P3)

Description

[Will]

Apologies if this is WONTFIX/INVALID but Windows 11 has expanded ALPF range compared to previous versions of Windows and Firefox should take advantage of this. Chromium version of this issue here https://bugs.chromium.org/p/chromium/issues/detail?id=1505793&no_tracker_redirect=1

Comment 1

[Ray Kraesig [:rkraesig]]

Wow, that's obscure. I wasn't able to find reasonable official documentation about it at all. Bug title adjusted appropriately.

https://learn.microsoft.com/en-us/archive/blogs/ryanmy/misinformation-and-the-the-prefetch-flag

The short version: at process-launch time, Windows inspects the command line looking for a /prefetch:# argument, and buckets the application-invocation differently in the prefetch cache if one is found. On the receiving end, we don't actually need to do anything other than recognize and discard this argument.

We already do some DLL preloading shenanigans, so this probably won't help much; but it also probably won't hurt.

Comment 2

[Will]

Thank you for looking at this! Apparently if you take advantage of the extended range available on Windows 11, there's enough wins to make it worthwhile. And all these little wins add up to make a big difference over time!

Comment 3

[Will]

Sorry for the double post but here's a couple more links about it https://learn.microsoft.com/en-us/powershell/module/mmagent/enable-mmagent?view=windowsserver2022-ps&ranMID=24542&ranEAID=kXQk6*ivFEQ&ranSiteID=kXQk6.ivFEQ-5F6c44Yx1m2YHPP4F9F6HQ&epi=kXQk6.ivFEQ-5F6c44Yx1m2YHPP4F9F6HQ&irgwc=1&OCID=AIDcmm549zy227_aff_7593_1243925&tduid=(ir__wi1pkan3ewkfdlbfrwbsc66or32x9ubxehpfifet00)(7593)(1243925)(kXQk6.ivFEQ-5F6c44Yx1m2YHPP4F9F6HQ)()

https://blogs.windows.com/windowsdeveloper/2014/05/01/launch-apps-faster-with-prefetched-content/

Comment 4

[Ray Kraesig [:rkraesig]]

Thanks, but:

• The former link describes how an end-user can enable or disable application launch prefetching across the whole system, but not how applications can or should take advantage of it.
• The latter link is strictly about prefetching web content using the .NET standard library.

Comment 5

[Ray Kraesig [:rkraesig]]

Attachment: Bug 1878993 - [1/1] Inform Windows about different process types r?#win-reviewers,#ipc-reviewers

Windows has an ill-documented subsystem known as the Application Launch
Prefetcher, which apparently preloads DLLs for a binary based on what
DLLs that binary loaded last time.

For Firefox, that's not a great heuristic; we relaunch ourselves as a
subprocess with potentially completely different DLL settings. We're not
the only such application, though, and Windows does have a way to
signal the ALPF to load different DLL sets depending on launch context.

Comment 6

[Yannis Juglaret [:yannis]]

(In reply to Ray Kraesig [:rkraesig] from comment #1)

We already do some DLL preloading shenanigans, so this probably won't help much; but it also probably won't hurt.

As noted by :glandium, it would be nice to evaluate if our manual prefetching is still useful after this patch lands. Maybe the patch will make Windows' default prefetching good enough already; or maybe it will make it even better than manual prefetching.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dccf526bcc0a
[1/1] Inform Windows about different process types  r=win-reviewers,yjuglaret

Comment 8

[Will]

Thank you for looking at this and just to reiterate, Windows 11 has an expanded ALPF range compared to previous versions of Windows, and Firefox taking advantage of that expanded range that's available on Windows 11 is probably what makes doing this worthwhile. That's what the Chromium bug I linked to in comment 0 is about https://bugs.chromium.org/p/chromium/issues/detail?id=1505793&no_tracker_redirect=1

Comment 9

[Ray Kraesig [:rkraesig]]

The patch does check the Windows version and uses the full gamut of prefetch-cache slots, as appropriate. (You can see for yourself, if you're interested: this isn't a security issue, so the patch is public.)

I'm not convinced that the expanded range makes much of a difference for us — Chromium seems to have a few more common process types than we do? — but the proof of the pudding is in the eating, so we shall see how it eats.

Comment 10

[Cristina Horotan [:chorotan]]

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

Comment 11

[Atila Butkovits]

Backed out for causing build bustages at GeckoChildProcessHost.cpp on central.

Backout link: https://hg.mozilla.org/integration/autoland/rev/8fb84cc4cc82895989b64a4282b534bec5d4b671

Push where failures started: https://treeherder.mozilla.org/jobs?repo=mozilla-central&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&searchStr=build&selectedTaskRun=A30D5HTGSoadFT2UTo3aGg.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=448321967&repo=mozilla-central&lineNumber=34714

Comment 12

[Cristian Tuns]

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/8fb84cc4cc82

Comment 13

[Ray Kraesig [:rkraesig]]

mSandbox, reasonably, doesn't exist when MOZ_SANDBOX is not defined. Fall back to Windows 10 behavior in this case.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/98eadcb92105
[1/1] Inform Windows about different process types  r=win-reviewers,ipc-reviewers,yjuglaret,nika

Comment 15

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/98eadcb92105

Comment 16

[Will]

Sorry for the ping but did this end up helping at all?

Comment 17

[Ray Kraesig [:rkraesig]]

No, thanks for the ping -- evaluating the performance effect had fallen off my to-do list.

Unfortunately, as far as I can tell from our Performance graphs, there was no particular change to our Windows startup metrics, positive or negative, circa 2024-03-06.

This isn't too surprising since we already had some DLL preloading code in-place (bug 1397706, etc.). This may allow for that to be removed or trimmed down... though given that we've previously had issues with Windows file caching behaving badly (see e.g. bug 627591), I suspect that in the end we'll probably prefer to stick with the in-house mechanisms that we have more control over (and more diagnostic insight into).

Comment 18

[Yannis Juglaret [:yannis]]

Attachment: Backed out changeset 98eadcb92105 (Bug 1878993) for causing bug 1892612. r=#win-reviewers

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)

Comment 20

[Cristian Tuns]

Backed out for causing Bug 1892612

• Backout link

Comment 21

[Cristian Tuns]

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/9c636b2e16c4

Comment 22

[Ray Kraesig [:rkraesig]]

Attachment: Backed out changeset 98eadcb92105 (Bug 1878993) for causing bug 1892612. r=#win-reviewers

Original Revision: https://phabricator.services.mozilla.com/D208112

Comment 23

[Ray Kraesig [:rkraesig]]

Attachment: Backed out changeset 98eadcb92105 (Bug 1878993) for causing bug 1892612. r=#win-reviewers

Original Revision: https://phabricator.services.mozilla.com/D208112

Comment 24

[Donal Meehan [:dmeehan]]

Comment on attachment 9397883 [details]
Backed out changeset 98eadcb92105 (Bug 1878993) for causing bug 1892612. r=#win-reviewers

Approved for 126.0b5

Comment 25

[Donal Meehan [:dmeehan]]

Backout merged to beta: https://hg.mozilla.org/releases/mozilla-beta/rev/9a7b8c392adc1a8d3fa146beef1c8ef5fb99ccea

Comment 26

[Ray Kraesig [:rkraesig]]

Attachment: Backed out changeset 98eadcb92105 (Bug 1878993) for causing bug 1892612. r=#win-reviewers

Original Revision: https://phabricator.services.mozilla.com/D208112

Comment 27

[Phabricator Automation]

release Uplift Approval Request

• User impact if declined: bug 1892612
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: https://bugzilla.mozilla.org/show_bug.cgi?id=1892612#c5
• Risk associated with taking this patch: low
• Explanation of risk level: backout of patch from this version
• String changes made/needed: none
• Is Android affected?: no

Comment 28

[Gian-Carlo Pascutto [:gcp]]

Unfortunately, as far as I can tell from our Performance graphs, there was no particular change to our Windows startup metrics, positive or negative, circa 2024-03-06.

It may be worthwhile keeping an eye on the in-the-field performance telemetry to see if this had an impact. Perhaps reach out to the performance team if you need help with this.

Comment 29

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Hello! We reproduced the issue with Firefox 125.0.2 on Windows 10x64 and Windows 11 by following steps from 1892612#c5. After executing firefox.exe --foo in CMD while Firefox is running a new tab will open containing the https://0.0.0.1/ address.

The issue is verified fixed with Firefox 127.0a1 (20240423214125) and 126.0b5 (20240422174749) from comment 25 on Windows 10x64 (22H2 build 19045.4291) and Windows 11 (23H2, build 22631.3447) using the same steps. After executing firefox.exe --foo in CMD while Firefox is running a new empty window will open as stated in 1892612#c5 and as on Firefox 124.0.2.

Leaving the qe+ flag until the backout is on 125.0.3 as well.

Comment 30

[Ryan VanderMeulen [:RyanVM]]

Backed out for 125.0.3 also.

Comment 31

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/40b6756b190f

Comment 32

[Alexandru Trif, Desktop Test Engineering [:atrif]]

The issue is verified fixed with Firefox 125.0.3 (20240425211020) on Windows 10x64 and Windows 11 x64. After executing firefox.exe --foo in CMD while Firefox is running a new empty window will open as stated in 1892612#c5 and as on Firefox 124.0.2.