Skip to content
Snippets Groups Projects
  1. Apr 13, 2022
  2. Apr 05, 2022
  3. Mar 22, 2022
  4. Mar 17, 2022
  5. Mar 16, 2022
  6. Feb 25, 2022
  7. Oct 06, 2021
  8. Oct 05, 2021
  9. Aug 25, 2021
    • Andi-Bogdan Postelnicu's avatar
      Bug 1725145 - Preparation for the hybrid build env.... · 2fc4f70e
      Andi-Bogdan Postelnicu authored
      Bug 1725145 - Preparation for the hybrid build env. r=necko-reviewers,firefox-build-system-reviewers,valentin,glandium
      
      Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
      when the module governed by the build config file is not buildable outside on the unified environment.
      
      This needs to be done in order to have a hybrid build system that adds the possibility of combing
      unified build components with ones that are built outside of the unified eco system.
      
      Differential Revision: https://phabricator.services.mozilla.com/D122345
      2fc4f70e
  10. Mar 23, 2021
  11. Feb 04, 2021
  12. Jan 27, 2021
  13. Jan 26, 2021
  14. Jan 25, 2021
  15. Nov 23, 2020
  16. Aug 27, 2020
  17. Aug 20, 2020
    • Doug Thayer's avatar
      Bug 1658732 - Replace mStartupFinished with TryLock in StartupCache r=froydnj · 5f41a2f5
      Doug Thayer authored
      To be honest, it's still a mystery why we observed a regression in
      sessionrestore_no_auto_restore in bug 1658732. The regression won't reproduce
      on profiled runs, and the bad recordings happen before the supposedly offending
      code ever actually runs. It feels most likely that it is a more or less random
      confluence of factors causing a regression; however, 33% is too large of a
      number to ignore.
      
      The changes in this patch do not seem to yield the same regression, and they
      are arguably more correct anyway. Instead of simply turning off the cache after
      startup is finished, we simply avoid blocking waiting for the write from inside
      GetBuffer. This way, if the write is not getting in the way of GetBuffer, we
      can still benefit from a cached version of whatever it is we're looking for.
      
      Differential Revision: https://phabricator.services.mozilla.com/D87221
      5f41a2f5
  18. Aug 18, 2020
  19. Sep 14, 2020
    • Doug Thayer's avatar
      Bug 1656261 - Back out all recent StartupCache work r=RyanVM · 025f5fb9
      Doug Thayer authored
      This backs out all work from bug 1627075 as well as all of its
      descendents. There were a few conflicts when backing this out but
      overall it was pretty clean, so I would say it's a fairly mild
      level of risk. Historically Nathan Froyd has reviewed these patches,
      but he is no longer at Mozilla, and no one else is particularly
      familiar with the code, so I am passing this off to RyanVM who has
      at least been familiar with the history of the bug.
      
      Differential Revision: https://phabricator.services.mozilla.com/D90096
      025f5fb9
  20. Sep 09, 2020
    • Doug Thayer's avatar
      Bug 1656261 - Ensure we clean up after WriteToDisk r=froydnj · 2b194eb9
      Doug Thayer authored
      Given all of the MOZ_TRYs in WriteToDisk, it's entirely possible that
      we occasionally exit it before writing everything out. WriteToDisk
      additionally adds guards to try to ensure that we do not call it twice,
      and that we do not try to read things out of the file via the memmapped
      buffer after it has written to it. The latter should not generally be
      a problem, since we write to a temp file and move that over at the end.
      However, writing twice could be a problem as we modify our values'
      mOffsets to keep track of their offsets within the resulting file.
      
      Accordingly, this change simply moves the cleanup and guards into an
      RAII helper to ensure they survive all of the early returns.
      
      Differential Revision: https://phabricator.services.mozilla.com/D89253
      2b194eb9
  21. Aug 07, 2020
    • Doug Thayer's avatar
      Bug 1656974 - Turn off StartupCache when startup is finished r=froydnj · 973cdcbc
      Doug Thayer authored
      I don't think this will fully resolve the shutdown hangs associated
      with this bug. The underlying problem is that writing the startup
      cache during shutdown can take a long time. This seems like A Bad Thing,
      and I have a mild leaning toward the thought that we shouldn't write the
      startup cache at all during shutdown. However, I do think that trading
      shutdown time regressions for startup time wins is probably good, so
      I don't feel super comfortable making that change.
      
      However, this change at least fixes the problem where we A) block the main
      thread waiting for the write to finish, and B) are more likely to hit a
      shutdown hang, since we concentrate all of the hang time in one phase,
      rather than it being spread across the shutdown timeline. This is likely
      the major change that the regressing bug introduced.
      
      The unfortunate consequence is that if we try to GetBuffer during shutdown,
      we will now read out of the omnijar. However, it should overall be better
      since we'll be waiting on a (hopefully) small number of small reads rather
      than a large write.
      
      Differential Revision: https://phabricator.services.mozilla.com/D86054
      973cdcbc
  22. Aug 06, 2020
  23. Aug 07, 2020
  24. Aug 06, 2020
    • Doug Thayer's avatar
      Bug 1656974 - Turn off StartupCache when startup is finished r=froydnj · d1082779
      Doug Thayer authored
      I don't think this will fully resolve the shutdown hangs associated
      with this bug. The underlying problem is that writing the startup
      cache during shutdown can take a long time. This seems like A Bad Thing,
      and I have a mild leaning toward the thought that we shouldn't write the
      startup cache at all during shutdown. However, I do think that trading
      shutdown time regressions for startup time wins is probably good, so
      I don't feel super comfortable making that change.
      
      However, this change at least fixes the problem where we A) block the main
      thread waiting for the write to finish, and B) are more likely to hit a
      shutdown hang, since we concentrate all of the hang time in one phase,
      rather than it being spread across the shutdown timeline. This is likely
      the major change that the regressing bug introduced.
      
      The unfortunate consequence is that if we try to GetBuffer during shutdown,
      we will now read out of the omnijar. However, it should overall be better
      since we'll be waiting on a (hopefully) small number of small reads rather
      than a large write.
      
      Differential Revision: https://phabricator.services.mozilla.com/D86054
      d1082779
  25. Oct 26, 2020
    • Ricky Stewart's avatar
      Bug 1654103: Standardize on Black for Python code in `mozilla-central`. · 02a7b4eb
      Ricky Stewart authored
      Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
      
      To produce this patch I did all of the following:
      
      1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
      
      2. Run ./mach lint --linter black --fix
      
      3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
      
      4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
      
      5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
      
      # ignore-this-changeset
      
      Differential Revision: https://phabricator.services.mozilla.com/D94045
      02a7b4eb
  26. Oct 24, 2020
    • Bogdan Tara's avatar
      Backed out 10 changesets (bug 1654103, bug 1672023, bug 1518999) for... · da1098d4
      Bogdan Tara authored
      Backed out 10 changesets (bug 1654103, bug 1672023, bug 1518999) for PanZoomControllerTest.touchEventForResult gv-junit failures CLOSED TREE
      
      Backed out changeset ff3fb0b4a512 (bug 1672023)
      Backed out changeset e7834b600201 (bug 1654103)
      Backed out changeset 807893ca8069 (bug 1518999)
      Backed out changeset 13e6b92440e9 (bug 1518999)
      Backed out changeset 8b2ac5a6c98a (bug 1518999)
      Backed out changeset 575748295752 (bug 1518999)
      Backed out changeset 65f07ce7b39b (bug 1518999)
      Backed out changeset 4bb80556158d (bug 1518999)
      Backed out changeset 8ac8461d7bd7 (bug 1518999)
      Backed out changeset e8ba13ee17f5 (bug 1518999)
      da1098d4
  27. Oct 23, 2020
    • Ricky Stewart's avatar
      Bug 1654103: Standardize on Black for Python code in `mozilla-central`.... · c0cea3b0
      Ricky Stewart authored
      Bug 1654103: Standardize on Black for Python code in `mozilla-central`. r=remote-protocol-reviewers,marionette-reviewers,webdriver-reviewers,perftest-reviewers,devtools-backward-compat-reviewers,jgilbert,preferences-reviewers,sylvestre,maja_zf,webcompat-reviewers,denschub,ntim,whimboo,sparky
      
      Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
      
      To produce this patch I did all of the following:
      
      1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
      
      2. Run ./mach lint --linter black --fix
      
      3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
      
      4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
      
      5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
      
      # ignore-this-changeset
      
      Differential Revision: https://phabricator.services.mozilla.com/D94045
      c0cea3b0
  28. Oct 22, 2020
  29. Oct 21, 2020
    • Ricky Stewart's avatar
      Bug 1654103: Standardize on Black for Python code in `mozilla-central`.... · 50762dac
      Ricky Stewart authored
      Bug 1654103: Standardize on Black for Python code in `mozilla-central`. r=remote-protocol-reviewers,marionette-reviewers,webdriver-reviewers,perftest-reviewers,devtools-backward-compat-reviewers,jgilbert,preferences-reviewers,sylvestre,maja_zf,webcompat-reviewers,denschub,ntim,whimboo,sparky
      
      Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
      
      To produce this patch I did all of the following:
      
      1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
      
      2. Run ./mach lint --linter black --fix
      
      3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
      
      4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
      
      # ignore-this-changeset
      
      Differential Revision: https://phabricator.services.mozilla.com/D94045
      50762dac
  30. Jul 22, 2020
    • Doug Thayer's avatar
      Bug 1651941 - Free unreferenced child StartupCache entries on send r=froydnj · 249401cc
      Doug Thayer authored
      This is similar to the first patch in the stack, but instead of freeing the
      entries on write, we free them when we send them to the parent to be written.
      
      Differential Revision: https://phabricator.services.mozilla.com/D83401
      249401cc
    • Doug Thayer's avatar
      Bug 1651941 - Avoid unnecessary empty StartupCaches r=froydnj · a538eb78
      Doug Thayer authored
      Prior to this patch, we were sending a boolean from InitContentChild (which
      creates our StartupCache IPC actors) indicating whether we wanted to collect
      new entries from a given process or not. This was so that we wouldn't accept
      PutBuffer requests in these processes, since collecting them in one process
      would be enough, and we don't want to waste memory. However, we actually
      want the cache to be available before we can even get that IPC constructor
      to the child process, so there's a window where we accept new entries
      no matter what. This patch changes this by sending a boolean argument via
      the command line indicating that we want to disable the Startupcache in this
      process entirely. We send this when we didn't load a StartupCache off disk,
      as this should be the only circumstance in which we're actually collecting
      a substantial number of entries in content processes.
      
      Differential Revision: https://phabricator.services.mozilla.com/D83400
      a538eb78
Loading