tl;dr: A major change to the architecture preference service has just landed,
so please be on the lookout for regressions.
We've been working for the last few weeks on rearchitecting the preference
service to work better in our current and future multi-process configurations,
and those changes have just landed in bug 1471025.
Our preference database tends to be very large, even without any user values.
It also needs to be available in every process. Until now, that's meant
complete separate copies of the hash table, name strings, and value strings in
each process, along with separate initialization in each content process, and
a lot of IPC overhead to keep the databases in sync.
After bug 1471025, the database is split into two sections: a snapshot of the
initial state of the database, which is stored in a read-only shared memory
region and shared by all processes, and a dynamic hash table of changes on top
of that snapshot, of which each process has its own. This approach
significantly decreases memory, IPC, and content process initialization
overhead. It also decreases the complexity of certain cross-process
synchronization logic.
But it adds complexity in other areas, and represents one of the largest
changes to the workings of the preference service since its creation. So
please be on the lookout for regressions that look related to preference
handling. If you spot any, please file bugs blocking https://bugzil.la/1471025.
Thanks,
Kris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
