browser_startupcache_telemetry.js fails with QuantumBar enabled

RESOLVED FIXED in Firefox 68

Status

()

defect
P1
normal
RESOLVED FIXED
5 months ago
4 months ago

People

(Reporter: intermittent-bug-filer, Assigned: standard8)

Tracking

(Blocks 1 bug, {regression})

unspecified
mozilla68
Points:
5
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox66 disabled, firefox67 disabled, firefox68 fixed)

Details

Attachments

(1 attachment)

#[markdown(off)]
Filed by: mbanner [at] mozilla.com

https://treeherder.mozilla.org/logviewer.html#?job_id=234494522&repo=try

https://queue.taskcluster.net/v1/task/Pr5cPsV_TSWVje8pwdGDCg/runs/0/artifacts/public/logs/live_backing.log

This is seen on our tests when enabling QuantumBar, it seems that we're expecting the cache to be read when opening a new browser window, but this is no longer happening.

Maybe with QuantumBar this is no longer needed? I can't see any easy documentation about what the cache actually stores.

Doug, could you take a look at this please? or give us some pointers?

If you want to try it locally, you'll want this patch for enabling QuantumBar: https://hg.mozilla.org/try/rev/ce812db425cc531589e857569ed471309719a531

Flags: needinfo?(dothayer)

Well for some reason, with quantumbar enabled these seven items load from the "disk" cache rather than from the "memory" cache:

xulcache/resource/app/chrome/browser/content/browser/browser.xul
jssubloader/global/resource/app/features/formautofill@mozilla.org/chrome/content/customElements.js
jssubloader/global/resource/app/chrome/browser/content/browser/browser-sync.js
jssubloader/global/resource/gre/chrome/toolkit/content/global/viewZoomOverlay.js
jssubloader/global/resource/app/chrome/browser/content/browser/browser-allTabsMenu.js
jssubloader/global/resource/app/chrome/browser/content/browser/browser-gestureSupport.js
jssubloader/global/resource/app/chrome/browser/content/browser/browser-thumbnails.js

"disk" and "memory" caches reflect what I had the histogram record, but they're not the most descriptive names. We're not actually reading from disk for any of these items, but we are calling inflate(...) for each of them, which seems less than ideal.

All of this seems to be due to how the "memory" cache (just a hash table (mTable)) is only populated when we call PutBuffer, not from the result of GetBuffer. Populating the cache in GetBuffer would incur an extra copy since the caller is supposed to take ownership of the resulting buffer.

In any case, I don't have a depth of familiarity with how all of this ought to work or why we're taking a different path with the quantumbar. kmag, does any of this ring any bells in your head?

Flags: needinfo?(dothayer) → needinfo?(kmaglione+bmo)

This may be a blocker for QB

Priority: P5 → P2
Points: --- → 5
Priority: P2 → P1

Let's just replace that assertion with one requiring that the memory cache hit is sufficiently low. I'm not sure why it's asserting != 0 now... that's not really what we want. It's just been passing up until now because without QuantumBar enabled, we wind up loading search-one-offs.js from the urlbarBindings desctructor when we close the test browser windows, and with it enabled we don't.

Flags: needinfo?(kmaglione+bmo)

I'll see if I can spin up a patch to match Kris' suggestions.

Assignee: nobody → standard8
Status: NEW → ASSIGNED

Try runs with the patch I'm just about to post:

Pushed by mbanner@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/95d45fef28b9
Relax the startup cache test restrictions to account for QuantumBar not loading search-one-offs.js. r=kmag
Iteration: --- → 68.3 - Apr 15 - 28
Iteration: 68.3 - Apr 15 - 28 → ---
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.