Platform/PrefsOverhaul

From MozillaWiki
Jump to: navigation, search

libpref has a lot of problems. The All About Prefs document describes libpref in detail and covers a lot of the problems. Because prefs are used so widely, these problems affect many people and many parts of the codebase.

In late 2017 and early 2018 nnethercote is overhauling libpref and fixing a lot of these problems. This page covers that work.

Major pieces

A lot of work has been done to generally clean up libpref's internals, e.g. see bug 1407526. This work is important, but this page will focus on larger changes, particularly those that affect how libpref is used.

[DONE] clang-format

Benefits

  • Improves readability.
  • Saves time going forward not having to make formatting decisions.

[DONE] merge-files

  • Combine all libpref C++ source files into one .cpp and one .h file.
  • bug 1407112

Benefits

  • Allows unnecessary internal interfaces and indirection to be removed. (Lots of these have been done, tracked under bug 1407526.)

[DONE] no-extension-prefs

  • Remove code supporting extension-specific prefs file, as supported by legacy extensions.
  • bug 1413413

Benefits

  • Less code.
  • Simpler libpref startup.

[DONE] new-parser

Benefits

  • New parser is faster.
  • New parser is safer (because it's written in Rust).
  • New parser is more correct and better tested (the old one got various obscure edge cases wrong).
  • New parser is more maintainable, much easier to modify.
  • New parser has error recovery and better error messages.
  • New parser catches integer overflow.
  • Unblocks default-pref-attributes.

Notes

  • New parser is slightly stricter, rejects some malformed input that the old parser accepted. Error recovery minimizes the risk of data loss, because malformed pref lines in prefs.js will be removed but well-formed pref lines afterwards are preserved.

[DONE] less-IPC

Benefits

  • Greatly reduces the amount of data the parent has to send to each new content process. On my Linux64 box:
    • Sent via the process command (early prefs): ~222 prefs --> ~3 prefs.
    • Sent via IPC (late prefs): ~3165 prefs --> ~180 prefs.
  • Makes content process commands smaller and nicer, fixing bug 1373157.
  • Avoids double initialization (hash table lookups) for all these prefs.
  • Unblocks no-early-late-split.

[DONE] default-pref-attributes

  • Introduce a distinction between the grammar used for default pref files and user pref files, with the former being more powerful.
  • Add "pref attributes" (boolean flags) to default prefs.
  • sticky and locked are the first two attributes.
  • bug 440908
  • Blog post ("Attributes" section at the end)

Benefits

  • Default prefs can now be locked in the data file (first requested 10 years ago).
  • Default/user grammar split means default user file format can evolve without affecting user files.
  • More info about each pref is in a single place; avoids the need for various blacklists/whitelists.
  • Additional attributes can be added in the future. Possibilities:
    • Not needed by content processes?
    • Show in about:support?
    • Show in about:config? (new)
    • Allow changing in about:config? (new)
    • Sync it?
    • Ignore in private browsing mode? (new)
    • Expire at some point in the future? (new)

[DONE] no-prefs-in-commands

  • Don't embed prefs in content process commands; use shared memory instead.
  • bug 1438678

Benefits

  • The amount of data passable via shared memory is much higher than via commands.
  • Minimizes potential bloat in content process commands.
  • Unblocks no-early-late-split.

[DONE] no-early-late-split

  • Pass all changed pref values (not just early prefs) to new content processes via shared memory.
  • bug 1436911

Benefits

  • Removes the need for the early prefs list (dom/ipc/ContentProcesses.{h,cpp}) and the associated checking, which is ugly and often trips people up (e.g. bug 1432979, bug 1439406).
  • Using prefnames instead of indices fixes some fragility (fixing bug 1419432)
  • Fixes the problem of early prefs being installed as unlocked default values even if they are locked and/or have user values.
  • Unblocks static-prefs.

[ON TRACK] static-prefs

  • Introduce a mechanism for prefs to be defined in the binary instead of a prefs data file.
  • Not all prefs will/should be defined in the binary, but for C++ only prefs this has some big advantages, esp. for VarCache prefs.
  • A lot of prefs can be converted, which will be a gradual process because there are so many of them.
  • bug 1436655 (mechanism), bug 1448219 (conversions)

Benefits

  • Less code to define and setup each pref.
  • More info about these prefs is in a single place, rather than two or more places; avoids error-prone duplication of prefnames and default values.
  • Prevent direct modification of VarCache prefs, which leads to consistency problems (e.g. bug 1438433).
  • Use of getters to access VarCache prefs allows checking when accessing VarCache prefs.
  • Use of getters avoids possible mistyping of pref names.
  • MediaPrefs can be removed. (But not gfxPrefs, yet; that's a harder nut to crack.)
  • Initializing from binary should be faster than parsing a data file.
  • Static prefs are usable from Rust code.
  • Unblocks less-racy-VarCache-prefs.

Downsides

  • Adding/removing/modifying one of these prefs causes a lot of recompilation.
    • bug 1564724 and bug 1563139 improved things by (a) generating the header file from a YAML file, and (b) splitting that generated header file into many smaller pieces, each one causing much less recompilation when changed.

[DONE] less-racy-VarCache-prefs

  • Use of VarCache getters allows detection of multi-threaded VarCache prefs that should be atomic.
  • bug 1436916

Benefits

  • Fewer races!
Retrieved from "https://wiki.mozilla.org/index.php?title=Platform/PrefsOverhaul&oldid=1216122"