browser_startupcache_telemetry.js fails with QuantumBar enabled
Categories
(Core :: XPCOM, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr60 | --- | unaffected |
| firefox66 | --- | disabled |
| firefox67 | --- | disabled |
| firefox68 | --- | fixed |
People
(Reporter: intermittent-bug-filer, Assigned: standard8)
References
Details
(Keywords: regression)
Attachments
(1 file)
#[markdown(off)]
Filed by: mbanner [at] mozilla.com
https://treeherder.mozilla.org/logviewer.html#?job_id=234494522&repo=try
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.
|
Assignee | |
Comment 1•6 years ago
|
||
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
|
||
Comment 2•6 years ago
•
|
||
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?
| Comment hidden (Intermittent Failures Robot) |
|
||
Updated•6 years ago
|
|
||
Updated•6 years ago
|
|
||
Comment 5•6 years ago
|
||
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.
|
|
Assignee | |
Comment 6•6 years ago
|
||
I'll see if I can spin up a patch to match Kris' suggestions.
|
|
Assignee | |
Comment 7•6 years ago
|
||
Try runs with the patch I'm just about to post:
- Without QuantumBar enabled: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5b1fe817ec7fad8c7fbbfc6f3a062d5a988b1933
- With QuantumBar enabled: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c55ac2c9924247cb998e1fdff0f7c8ee0ebd451a&selectedJob=239005757
- (the oranges are a different test that we're working on fixing for QuantumBar).
|
|
Assignee | |
Comment 8•6 years ago
|
||
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
|
||
Updated•6 years ago
|
|
|
||
Updated•6 years ago
|
|
||
Comment 10•6 years ago
|
||
| bugherder | ||
|
||
Updated•6 years ago
|
Description
•