This makes it possible to use different lists for tracking protection
and for the features that rely on tracking annotations.
Differential Revision: https://phabricator.services.mozilla.com/D2484
--HG--
extra : moz-landing-system : lando
It was accidentally changed from 524288 to 32768 on Android by bug 1448222.
This commit changes it back.
--HG--
extra : rebase_source : 9181928dccf0cfcd0f70c1c3840d43c378f38ca4
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle
that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the place.
Additionally, if moving entries is implemented via memcpy (which is
quite common), PLDHashTable copying around bits *again* is inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead
of copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
Renamed the pref media.webrtc.rsdparsa_enabled to media.peerconnection.sdp.rust.compare
Added the pref media.peerconnection.sdp.rust.enabled
Added both to all.js
media.peerconnection.sdp.rust.compare: Controls whether the parsing result comparer for sipcc and rsdparsa runs or not.
media.peerconnection.sdp.rust.enabled: Controls whether the rsdparsa runs in parallel to the sipcc parser.
MozReview-Commit-ID: Ac5P7T2NBYD
--HG--
extra : rebase_source : afd60243ccba27965bea193bbe29d91bf7bf2644
Adds a performance counter in ParentAPIManager to track the
number and duration of API calls by webextensions.
MozReview-Commit-ID: PTpaSCkE6A
--HG--
extra : rebase_source : 21c6c7f2e38c8808771fe4fea90d2750196202bd
Adds a performance counter in ParentAPIManager to track the
number and duration of API calls by webextensions.
MozReview-Commit-ID: PTpaSCkE6A
--HG--
extra : rebase_source : e9a61cf0cf755db96f1fd0dacbc2744fe19fe08e
The current code is somewhat non-obvious to a first-time reader, and
OS_TEST is a bizarre thing anyway, since it's actually the name of the
CPU we're running on. We'd do well to minimize the use of OS_TEST.
Note that the complete nuking of the xptcall/md/unix/moz.build lines are
because we don't support OS X/x86 anymore.
In order to avoid the overhead of doing a full pref lookup for every static
var cache at content process startup, we currently assume that the default
value of any static varcache pref will always match the default value of its
database entry (as long as the pref isn't locked). This lets us only perform
lookups for preferences which have a user value, or are locked.
If the default values of those preferences are changed in a bundled preference
file, though, the varcache value will be correct in the parent process, but
not in child processes. Since this is an easy mistake to make, we should
assert that it doesn't happen.
Note: This change only affects applications which use e10s. Applications like
Thunderbird can still override default values of any static pref with
impunity. Repacks and distributors can only do so by changing user values or
locking the preference after the change (which is the standard practice for
enterprise deployments).
MozReview-Commit-ID: JMHQBrp9HN
--HG--
extra : source : 1b389b00030ed38cdb3543aa5d1a67795be47565
extra : amend_source : 16f2dccf40664db9daa42a6edaabb933acbc6204
In order to avoid the overhead of doing a full pref lookup for every static
var cache at content process startup, we currently assume that the default
value of any static varcache pref will always match the default value of its
database entry (as long as the pref isn't locked). This lets us only perform
lookups for preferences which have a user value, or are locked.
If the default values of those preferences are changed in a bundled preference
file, though, the varcache value will be correct in the parent process, but
not in child processes. Since this is an easy mistake to make, we should
assert that it doesn't happen.
Note: This change only affects applications which use e10s. Applications like
Thunderbird can still override default values of any static pref with
impunity. Repacks and distributors can only do so by changing user values or
locking the preference after the change (which is the standard practice for
enterprise deployments).
MozReview-Commit-ID: JMHQBrp9HN
--HG--
extra : rebase_source : 2f51295def52cbca316227f202158cb22656441a
The patch introduces NS_GetURIWithNewRef and NS_GetURIWithNewRef which perform the same function.
Differential Revision: https://phabricator.services.mozilla.com/D2239
--HG--
extra : moz-landing-system : lando
Pending figuring out how we want to block autoplay of WebAudio content, we
should just not block it by default for the initial release of block autoplay,
and follow up once we've figured out how to not break the web.
MozReview-Commit-ID: ClfdrHcugLs
--HG--
extra : rebase_source : 54f61b0765f1d0ed9c754c90da9c2809a7de8676
The prefs, when enabled, will dump the gecko DL items followed by the
WR DL items that were generated from that gecko item. This allows us to
easily go from a DOM element with known id/class attributes to e.g. an
ImageKey of an image that was generated for that element.
Also, this logging can be enabled in CI builds just like gecko display-list
dumping, instead of the ifdef that we previously had in WebRenderLayerManager.
MozReview-Commit-ID: Eeo4iO62YY1
--HG--
extra : rebase_source : b4a348b2e8bced976489257b966f70b29c56df25
This is probably the last thing we will ship since it needs the most spec work.
MozReview-Commit-ID: LLmDBLCsCBJ
--HG--
extra : rebase_source : c06752c9201a9ede87e1ac200ab12577bf784ce6
This feature should not be shipped until the various definitions of addition for
each additive property are properly specified.
Unlike other patches in this series, compositing is not frequently used
internally (e.g. by DevTools etc.) so there is no need to enable this by default
for system code.
Also, it turns out we have inadvertently been shipping part of this feature for
some time now. The next patch in this series will add tests for that case and
disable that part of the feature (a suitable intent to unship will follow). This
patch merely adapts and extends the existing tests without affecting the surface
area covered by the combination of the newly-added pref and the existing
dom.animations-api.core.enabled pref.
MozReview-Commit-ID: Htr6mlyCBav
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_compositing.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_compositing.html
extra : rebase_source : 7715a25e59568eb122ba3f7dbd2c2b2ffdd19954
This preference controls whether authors are allowed to specify animations
without a 0% or 100% keyframe.
We intend to ship this soon but this preference acts as a safeguard in case we
discover we need to disable it.
This feature is very convenient and commonly used so this patch ensures it is
always enabled for system content.
MozReview-Commit-ID: BHTsuS2xO61
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_implicit_keyframes.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_implicit_keyframes.html
extra : rebase_source : 04fd93dd26a4765c14b0b22febdb0311b650ea59
We don't intend to ship this in the near future until the integration with
AnimationWorklet is clear (although we might ship a read-only version).
That said, we use this feature extensively internally (e.g. in DevTools etc.) so
we enable this feature for system callers.
MozReview-Commit-ID: AhB7ZmU1Xzw
--HG--
extra : rebase_source : 630d7dc56b44a9261bb34aa5417cb9b7050efba4
I also tried to avoid this change but, again, given the number of times I was
repeating the same pattern of defining a static method just to forward a
callback to an instance method, decided it was probably necessary. Without an
easy way to do this, people are more likely to register observers rather than
callbacks, for which we'll wind up paying a continued memory and performance
penalty.
This patch adds a helper which creates a type-safe preference callback
function which forwards calls to an instance method on its closure object.
The implementation is somewhat complicated, mainly due to the constraint that
unregistering a callback requires passing the exact same function pointer that
was used to register it. The patch achieves this by creating the callback
function as a template, with the method pointer as a template parameter. As
long as the Register and Unregister calls happen in the same translation unit,
the same template instance is guaranteed to be used for both.
The main difficulty is that, until C++ 17, there's no way match a value as a
template parameter unless you know its complete type, or can at least compute
its complete type based on earlier template parameters. That means that we
need a macro to extract the type of the method, and construct the template
with the full set of explicit parameters.
MozReview-Commit-ID: 10N3R2SRtPc
--HG--
extra : rebase_source : 7d0a8ddeb77e01d4a6f421459514e93bc0875598
I initially tried to avoid this, but decided it was necessary given the number
of times I had to repeat the same pattern of casting a variable to void*, and
then casting it back in a part of code far distant from the original type.
This changes our preference callback registration functions to match the type
of the callback's closure argument to the actual type of the closure pointer
passed, and then casting it to the type of our generic callback function. This
ensures that the callback function always gets an argument of the type it's
actually expecting without adding any additional runtime memory or
QueryInterface overhead for tracking it.
MozReview-Commit-ID: 9tLKBe10ddP
--HG--
extra : rebase_source : 7524fa8dcd5585f5a31fdeb37d95714f1bb94922
Preference callbacks consume a non-trivial amount of memory, which adds up
fast given the number of callbacks we register.
Many of our consumers, however, register a large number of callbacks with the
same function and closure object, but different preference names or prefixes.
Since our callback matching is nothing more complicated than iteration over
all of our registered callbacks, there's nothing that prevents us from
combining all of these into a single callback, with an array of preferences
rather than a single string.
And since we already allocate an extra 8 bytes for each callback object, we
can add a variant tag without increasing our allocation size.
MozReview-Commit-ID: I497lWfMUp3
--HG--
extra : rebase_source : bac374d9a590c325728551d1669ebc6ef8ca3884
This patch addresses an issue with Firefox's proxy detection on networks which
do not have their a proxy auto-configuration (PAC) file hosted at
http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting
the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/
for an introduction to the protocol.
Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just
looked for a PAC file at http://wpad/wpad.dat
This patch only addresses the issue for Firefox on Windows, although it defines a
DHCP client interface which could be implemented on other platforms.
The high-level components of this patch are:
* nsIDHCPClient.idl - this is an interface which has been defined for querying the
DHCP server.
* nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of
http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy
thread. The class ExecutePACThreadAction has been augmented to include an
instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class,
'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC
file) back to the nsPACMan object.
* nsProtocolProxyService.cpp
Minor changes to reflect the fact that the PAC URL not being set does not always
mean there is no PAC to be used; instead it could be in the process of being
detected.
* TestPACMan.cpp
This is a new file, and tests only the DHCP auto-detect functionality.
Some tests use multiple threads, as they test the non-blocking proxy detection.
* DHCPUtils.cpp
A class containing the main logic for querying DHCP.
* WindowsNetworkFunctionsWrapper.cpp
A very thin wrapper around the Windows API calls needed by DHCPUtils.
This class was introduced so it could be mocked out in tests.
* nsWindowsDHCPClient.cpp
* An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin:
most logic is implemented in DHCPUtils.
* TestDHCPUtils.cpp
Tests for DHCPUtils and nsWindowsDHCPClient
MozReview-Commit-ID: 4xFQz3tOLEx
--HG--
extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
The preference storage in the shared memory snapshot is much more compact than
the dynamic hashtable, and is already mapped in memory, so there's no need to
keep the full hashtable in memory in the parent process after the snapshot is
created.
This patch empties the hashtable and the name string arena after the snapshot.
It also removes the accounting for preferences which have changed after init,
since those are, by definition, exactly the set of entries in the dynamic
hashtable.
MozReview-Commit-ID: L6VGq2z4foH
--HG--
extra : intermediate-source : 6c72dc1bff88e81f6c754b0971a44b9592d17ee1
extra : absorb_source : 321a2ac3a2d26bbe089c2183e25fccc85d8689f3
extra : source : 599895de063ef005dbd34847db9ee555410a878f
extra : histedit_source : 5905f462ea3d1c935addbe847e53a7d8589f6f38
With the parent sending a snapshot of its preference state at content process
startup, we're guaranteed to have the full set of built-in preferences in the
shared map at initialization time, so there's no need to load them again.
This also applies to static preference default values, so we skip setting
those, as well.
However, we do need to make sure that we update static preference cache
entries whose default values don't match the value in the shared map, since
they may have been changed by user preference files. In order to deal with
that, we iterate over all preferences in the map, and dispatch callbacks for
any that have user values.
MozReview-Commit-ID: DlRUbg7Qor3
--HG--
extra : intermediate-source : 7f4cc96fae1212cb2220770ac7311b9cc51af744
extra : absorb_source : 7c71a5994c26c2a1e34b291947a49ac5b3d633cb
extra : source : dc7ec17179d1961d91b897cec9f409786363ec9e
extra : histedit_source : f7c7a935e72af65446c2abc502744a066a6e2ae5%2C5cd3235724af3e5f22b772de171cea735ec4c047
This patch changes our preference look-up behavior to first check the dynamic
hashtable, and then fall back to the shared map.
In order for this to work, we need to make several other changes as well:
- Attempts to modify a preference that only exists in the shared table
requires that we copy it to the dynamic table, and change the value of the
new entry.
- Attempts to clear a user preference with no default value, but which also
exists in the shared map, requires that we keep an entry in the dynamic
table to mask the shared entry. To make this work, we change the type of
these entries to None, and ignore them during look-ups and iteration.
- Iteration needs to take both hashtables into consideration. The
serialization iterator for changed preferences only needs to care about
dynamic values, so it remains unchanged. Most of the others need to use
PrefsIter() instead.
MozReview-Commit-ID: 9PWmSZxoC9Z
--HG--
extra : intermediate-source : b4f9178f132de2b5f7064df9a9e1b489ea6576c3
extra : absorb_source : 57fd90ea8195adff9d314b813e94dc643fd085e4
extra : source : 5051f15fc2005667cfe76ccae0afb1fb0657c103
extra : histedit_source : 2ebf0e90a5e1b65795b20e9269def7cbbf2d1f11
Since lookups in the snapshotted hashtable are currently O(log n) rather than
O(1), they're expected to be slightly more expensive than the previous
purely-dynamic lookups.
In general, I expect this not to be a major issue. The main concern is pref
cache lookups while initializing the database. Initialization in the parent
process will still always use only a dynamic hashtable, so the performance
characteristics there won't change.
In the child process, though, we'll still need to notify observers of
preferences in the snapshot when they have user values, which could require
any number of lookups at startup (though in practice probably will not).
This patch solves that problem by caching the wrapper for the current known
preference value when dispatching callbacks, and optimizing lookups for that
value when it is present.
MozReview-Commit-ID: 2CAn0rM0bE9
--HG--
extra : intermediate-source : 8eff817d2f7e07409269899c048a9091220dec07
extra : absorb_source : 2609b4d9d1d994e19f884de1d1fba38347d35729
extra : source : faef4df47b2089592df7637f5b8f4ae193e98046
extra : histedit_source : b8a1e41ac70ad3eea354c375fb5f6813c0284a0d
For memory efficiency in content processes, we need to be able to store
changed preferences in a separate dynamic hashtable when their values don't
match the snapshot values.
That makes iteration over the full set of preferences somewhat more
complicated, since not only do we need to iterate over two tables, but we also
need to ignore preferences in the snapshot table if they also exist in the
dynamic hashtable.
This patch solves that problem by adding an iterator helper which iterates
over values in both tables, and skips values in the static table if they also
exist in the dynamic table.
In order to support completely deleting preferences that exist in the base
table, it also ignores all dynamic entries with the None type, so that they
can completely mask deleted base table values.
MozReview-Commit-ID: LCIwyPJMByj
--HG--
extra : intermediate-source : f9362cf1add47c2f62529e42764ed6088d274170
extra : absorb_source : fdaf890e85af43271cffd2371cf6fbf408c6cc50
extra : source : d344247b870668f53fa645e72bda4bb4309346c8
extra : histedit_source : 6cd565727eff617eeba386b563477ce4d4bfbd0a
The in-memory format of shared-memory preferences is significantly different
from the format used by dynamic preferences, which means that we need
different classes to access their properties.
Virtual classes would be a potential solution to this problem, but I don't
think the performance characteristics would be acceptable for preferences
code. And since the wrapper classes used for static prefs are temporary, they
would add the additional snag of figuring out how to keep a valid pointer
alive.
So, instead, this patch adds a wrapper class that can access either type of
preference, based on known type flags in a Variant. It also moves some of the
logic for deciding which preference value to return to the wrapper, so that it
doesn't need to be duplicated for each representation.
MozReview-Commit-ID: LameIIbYcD3
--HG--
extra : intermediate-source : ce379eaab17905f39f1665c3e40f683ebd3f8824
extra : absorb_source : eb5ed3380613e070eff5f9c9501e2640a6d398f9
extra : source : 83d98ea5ebaccded8a20929c0f3316e5618f1f76
extra : histedit_source : 634d033608f72294f6fc34d4449fe0f003758c74
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : intermediate-source : 46a6f9d0773ba2d756d8801cee79bfa994165d44
extra : absorb_source : a725a095946946797fd4f3abe6461e810b15d899
extra : source : e3bbc87b71af2f2ce1fa8bdf2cf26857c071ba5e
extra : histedit_source : 958212e804df7f9e1be6af182e73edc956b9a576
This is based on the SharedStringMap that's currently used for shared memory
string bundles.
When the parent process is ready to launch its first content process, it
creates a snapshot of the current state of the preference database, maps that
as read-only, and shares it with each content process. Look-ups in the
snapshotted map are done entirely using data in the shared memory region. It
doesn't require any additional per-process state data.
MozReview-Commit-ID: BdTUhak7dmS
--HG--
extra : intermediate-source : 434106f1b75e3ba900912f261bd22a1b7f5c931d
extra : absorb_source : 647ad37590448ad3c1eb8eb512bf671f262fa96e
extra : source : 68bb03c63b3cee1d47cbddfd3abf919f5783c04b
extra : histedit_source : 2228a9f8395929f5072a3c5ebda6ae3221e4a62d
Once the majority of preferences are stored in a read-only shared map, it
won't be possible to modify the access counts in their entries. Which means we
need a separate map for the access counts.
Fortunately, this code is only active in debug builds, so it shouldn't affect
release users. And the net impact on memory usage of this patchset will still
be decidedly downward.
MozReview-Commit-ID: EuLXlMQJP1M
--HG--
extra : intermediate-source : c490838c8329f6b0c21fa57ef078c44bf7a9ba8d
extra : absorb_source : 37a0f7a5fecba6c28bd6ce30644543c6d60ac823
extra : source : 4a8fbb472c91f13554cac3d0ea638cf9f368ff11
extra : histedit_source : 0e5a5f1cded97bcc959be15aa7194c017fd7efcc%2Cc0ae2011b9b40e6445ee366303f8ec4bb10cc87b
The preference storage in the shared memory snapshot is much more compact than
the dynamic hashtable, and is already mapped in memory, so there's no need to
keep the full hashtable in memory in the parent process after the snapshot is
created.
This patch empties the hashtable and the name string arena after the snapshot.
It also removes the accounting for preferences which have changed after init,
since those are, by definition, exactly the set of entries in the dynamic
hashtable.
MozReview-Commit-ID: L6VGq2z4foH
--HG--
extra : source : 599895de063ef005dbd34847db9ee555410a878f
extra : histedit_source : a3bcc573e29a60a61abaa1b2cc6daa87d6b1a946
With the parent sending a snapshot of its preference state at content process
startup, we're guaranteed to have the full set of built-in preferences in the
shared map at initialization time, so there's no need to load them again.
This also applies to static preference default values, so we skip setting
those, as well.
However, we do need to make sure that we update static preference cache
entries whose default values don't match the value in the shared map, since
they may have been changed by user preference files. In order to deal with
that, we iterate over all preferences in the map, and dispatch callbacks for
any that have user values.
MozReview-Commit-ID: DlRUbg7Qor3
--HG--
extra : source : dc7ec17179d1961d91b897cec9f409786363ec9e
extra : histedit_source : 285a99038c6731fed427cd8bc783b65f56e34ebb
This patch changes our preference look-up behavior to first check the dynamic
hashtable, and then fall back to the shared map.
In order for this to work, we need to make several other changes as well:
- Attempts to modify a preference that only exists in the shared table
requires that we copy it to the dynamic table, and change the value of the
new entry.
- Attempts to clear a user preference with no default value, but which also
exists in the shared map, requires that we keep an entry in the dynamic
table to mask the shared entry. To make this work, we change the type of
these entries to None, and ignore them during look-ups and iteration.
- Iteration needs to take both hashtables into consideration. The
serialization iterator for changed preferences only needs to care about
dynamic values, so it remains unchanged. Most of the others need to use
PrefsIter() instead.
MozReview-Commit-ID: 9PWmSZxoC9Z
--HG--
extra : source : 5051f15fc2005667cfe76ccae0afb1fb0657c103
extra : histedit_source : 28f2216b8c1e9d08ed9b2c03910d4b8434e55421
Since lookups in the snapshotted hashtable are currently O(log n) rather than
O(1), they're expected to be slightly more expensive than the previous
purely-dynamic lookups.
In general, I expect this not to be a major issue. The main concern is pref
cache lookups while initializing the database. Initialization in the parent
process will still always use only a dynamic hashtable, so the performance
characteristics there won't change.
In the child process, though, we'll still need to notify observers of
preferences in the snapshot when they have user values, which could require
any number of lookups at startup (though in practice probably will not).
This patch solves that problem by caching the wrapper for the current known
preference value when dispatching callbacks, and optimizing lookups for that
value when it is present.
MozReview-Commit-ID: 2CAn0rM0bE9
--HG--
extra : source : faef4df47b2089592df7637f5b8f4ae193e98046
extra : histedit_source : 3af498eac94f481523e86c31b9c2b3e55b3cd1fb
For memory efficiency in content processes, we need to be able to store
changed preferences in a separate dynamic hashtable when their values don't
match the snapshot values.
That makes iteration over the full set of preferences somewhat more
complicated, since not only do we need to iterate over two tables, but we also
need to ignore preferences in the snapshot table if they also exist in the
dynamic hashtable.
This patch solves that problem by adding an iterator helper which iterates
over values in both tables, and skips values in the static table if they also
exist in the dynamic table.
In order to support completely deleting preferences that exist in the base
table, it also ignores all dynamic entries with the None type, so that they
can completely mask deleted base table values.
MozReview-Commit-ID: LCIwyPJMByj
--HG--
extra : source : d344247b870668f53fa645e72bda4bb4309346c8
extra : histedit_source : bb670afc815f3953ccadebddd04962836569b281
The in-memory format of shared-memory preferences is significantly different
from the format used by dynamic preferences, which means that we need
different classes to access their properties.
Virtual classes would be a potential solution to this problem, but I don't
think the performance characteristics would be acceptable for preferences
code. And since the wrapper classes used for static prefs are temporary, they
would add the additional snag of figuring out how to keep a valid pointer
alive.
So, instead, this patch adds a wrapper class that can access either type of
preference, based on known type flags in a Variant. It also moves some of the
logic for deciding which preference value to return to the wrapper, so that it
doesn't need to be duplicated for each representation.
MozReview-Commit-ID: LameIIbYcD3
--HG--
extra : source : 83d98ea5ebaccded8a20929c0f3316e5618f1f76
extra : histedit_source : b3fc33ea04357e15323c7bcb1d02e73c1a9b0c76
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : source : e3bbc87b71af2f2ce1fa8bdf2cf26857c071ba5e
extra : histedit_source : dc1c7c8015e0443eed218f826fda9f5b38b3e062%2C4cfa2f90104ca3e907607d884ac86f73ad4995bf
This is based on the SharedStringMap that's currently used for shared memory
string bundles.
When the parent process is ready to launch its first content process, it
creates a snapshot of the current state of the preference database, maps that
as read-only, and shares it with each content process. Look-ups in the
snapshotted map are done entirely using data in the shared memory region. It
doesn't require any additional per-process state data.
MozReview-Commit-ID: BdTUhak7dmS
--HG--
extra : source : 68bb03c63b3cee1d47cbddfd3abf919f5783c04b
Once the majority of preferences are stored in a read-only shared map, it
won't be possible to modify the access counts in their entries. Which means we
need a separate map for the access counts.
Fortunately, this code is only active in debug builds, so it shouldn't affect
release users. And the net impact on memory usage of this patchset will still
be decidedly downward.
MozReview-Commit-ID: EuLXlMQJP1M
--HG--
extra : source : 4a8fbb472c91f13554cac3d0ea638cf9f368ff11
Andrea Marchesini
Francois Marier
Dorel Luca
Johannes Willbold
Anny Gakhokidze
Robert Longson
Nicholas Nethercote
Cosmin Sabou
Coroiu Cristina
Nathan Froyd
Tarek Ziadé
Ehsan Akhgari
Kris Maglione
Brian Hackett
Narcis Beleuzu
Gurzau Raul
shindli
Liang-Heng Chen
Brindusan Cristian
Tim Nguyen
Emilio Cobos Álvarez
Valentin Gosu
Jean-Yves Avenard
Tom Schuster
Noemi Erli
Nils Ohlmeier [:drno]
Tiberius Oros
Chris Pearce
Alex Chronopoulos
Kartikaya Gupta
Margareta Eliza Balazs
Xidorn Quan
Ryan Hunt
Andreea Pavel
Brian Birtles
Polly Shaw