1784479 - A gfxFontCache timer wakes up idle content processes every 10s forever

Status: RESOLVED DUPLICATE of bug 1789693

(Core :: Layout: Text and Fonts, defect)

Description

[Florian Quèze [:florian]]

+++ This bug was initially created as a clone of Bug #1736868 +++

A "gfxFontCache" timer fires every 10s in some processes (I think that's in all processes that have ever used fonts). I think this may be a regression, as I don't see this 10s timer in the profile I shared in bug 1736868 10 months ago.

Example profile: https://share.firefox.dev/3dsPalB (I profiled a fully idle Nightly with only one window displaying about:blank; in case this matters, this was on Windows with the most recent Nightly)

The Parent Process, WebExtension process, WebContent (4/4) process (the process of the visible about:blank tab) and the Privileged Content process all have "gfxFontCache" timers firing every 10s, apparently forever.

That 10s timer value is set at https://searchfox.org/mozilla-central/rev/6ec440e105c2b75d5cae9d34f957a2f85a106d54/gfx/thebes/gfxFont.cpp#184

I think this timer should be stopped once there's nothing left to expire in the caches.

There's a similar timer called gfxFontCache::WordCacheExpiration that fires 3 times (with 60s in between) in the Parent Process and the Privileged Content process: https://share.firefox.dev/3QGhqiO I don't understand why it takes 3 minutes to reach the point where this timer is removed, but at least (since bug 1736868) it no longer keeps repeating forever.

In my profile, this "gfxFontCache" timer seems to be the most common source of wake-ups for idle content processes. (And in the inactive parent process I think this might be the second most common, after another 5s timer from the nsUserIdleService.)

Comment 1

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Jonathan, can we do something for comment 0?

Comment 2

[Jonathan Kew [:jfkthame]]

The gfxFontCache is based on ExpirationTrackerImpl, which should cancel its timer when everything has expired from the tracker. So this suggests that for some reason not all gfxFont instances are expiring as expected.

There have been some recent changes to gfxFont refcounting and tracking, in bug 1779519 and bug 1780193, so I'm wondering if that has inadvertently broken something here.

cc'ing Andrew in case he can find some cycles to look into this before I get to it...

Comment 3

[Andrew Osmond [:aosmond] (he/him)]

We discussed this, and there are a few instances where we may hold strong pointers to gfxFont outside the cache, that are not on the stack. This is the cause of the timer continuing to tick indefinitely. We need to rework how we do expirations as a result.

Comment 4

[Florian Quèze [:florian]]

I encountered this bug again today while profiling. It's not just content processes, it also happens in the webextensions process and the parent process.

(In reply to Andrew Osmond [:aosmond] (he/him) from comment #3)

there are a few instances where we may hold strong pointers to gfxFont outside the cache, that are not on the stack.

Are these strong points bugs that need to be tracked down and fixed, or is this the intended behavior?

This is the cause of the timer continuing to tick indefinitely. We need to rework how we do expirations as a result.

Do you know what needs to happen? Is this bug actionable?

Comment 5

[Jonathan Kew [:jfkthame]]

I think the patch in bug 1789693 should mitigate this -- Andrew, is anything blocking that from landing at this point?

Comment 6

[Florian Quèze [:florian]]

This was fixed in bug 1789693, thanks!