Much like the component manager, many of the strings that we use for category
manager entries are statically allocated. There's no need to duplicate these
strings.
This patch changes the category manager APIs to take nsACStrings rather than
raw pointers, and to pass literal nsCStrings when we know we have a literal
string to begin with. When adding the category entry, it then skips making
copies of any strings with the LITERAL flag.
MozReview-Commit-ID: EJEcYSdNMWs
***
amend-catman
--HG--
extra : source : aa9a8f18e98f930a3d8359565eef02f3f6efc5f9
extra : absorb_source : 81a22ab26ee8017ac43321ff2c987d8096182d37
Our factory registrations already require that we store nsID pointers, which
we generally handle by using pointers to static data, or arena allocating a
copy of a dynamic ID.
Since we already have viable pointers to these IDs, there's no reason to store
an entire second copy for our hash key. We can use the pointer, instead, which
saves 16 bytes per entry.
MozReview-Commit-ID: 6MgKrXRSHv4
--HG--
extra : source : 5fb0b7746a5d56563b471e3061ccca124ea45485
extra : absorb_source : 275f5d4dc2c02e3d0391ed16e8690dac1e601758
Most of our components are static, and registered using literal C strings. For
those components, we currently use a nsDependentCString as a key when creating
a hash entry, which leads to an unnecessary duplication. Using literal
CStrings instead avoids the duplication.
MozReview-Commit-ID: 5DOUF8ZQMlh
--HG--
extra : source : 8359f8fe418419c50ab0ed93496e7445b570ba9f
extra : absorb_source : 2a33ae4e7e6d312adcea8ece2158f07a7050e01e
This takes 16 bytes off of the allocated size of each instance.
MozReview-Commit-ID: AhfN6MWvVL1
--HG--
extra : rebase_source : badc6ab690f2c4e0184ac0b51b29f81fb11279c6
extra : absorb_source : 0f685515a6946c89e9467c8b1e8548c989b1907b
extra : histedit_source : 7bfb5db39b23c1d262819c22a6e5fcd884c52504
We don't have a way to determine these at runtime, but for Windows and Linux,
the values are known and predictable.
MozReview-Commit-ID: 57LMJLzl762
--HG--
extra : rebase_source : 415690574116d549171097cb9e33834e4d4a9a4f
extra : absorb_source : 4678306b020999f52dcf770d3907d79f1f38b249
extra : histedit_source : 0d0f3cb62b9f64322876fe568ccd62893e6ad4b1%2Ccaca0524b930cf93608565ec06247aa0f4fee7e2
This adds reporting for heap overhead from nsThread and PRThread wrappers, as
well as thread event queues. It does not, currently, include overhead from
PlatformThread or js::Thread wrappers.
MozReview-Commit-ID: 6DkvbbkjHXm
--HG--
extra : rebase_source : 79df7172387fa1f952c43b06db644390be6f0d8a
This was moved out of nsThread in bug 1350432, but some dead code was left
behind.
MozReview-Commit-ID: BOhykHyIEPp
--HG--
extra : rebase_source : 21d4f95a019ba10851fba1efc588d6c2678aed85
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
Much like the component manager, many of the strings that we use for category
manager entries are statically allocated. There's no need to duplicate these
strings.
This patch changes the category manager APIs to take nsACStrings rather than
raw pointers, and to pass literal nsCStrings when we know we have a literal
string to begin with. When adding the category entry, it then skips making
copies of any strings with the LITERAL flag.
MozReview-Commit-ID: EJEcYSdNMWs
***
amend-catman
--HG--
extra : rebase_source : 4f70e7b296ecf3b52a4892c92155c7c163d424d2
Our factory registrations already require that we store nsID pointers, which
we generally handle by using pointers to static data, or arena allocating a
copy of a dynamic ID.
Since we already have viable pointers to these IDs, there's no reason to store
an entire second copy for our hash key. We can use the pointer, instead, which
saves 16 bytes per entry.
MozReview-Commit-ID: 6MgKrXRSHv4
--HG--
extra : rebase_source : 8d41a3fc5bc1ffe88af998bf9a0ba9ac3331a085
Most of our components are static, and registered using literal C strings. For
those components, we currently use a nsDependentCString as a key when creating
a hash entry, which leads to an unnecessary duplication. Using literal
CStrings instead avoids the duplication.
MozReview-Commit-ID: 5DOUF8ZQMlh
--HG--
extra : rebase_source : 57d151df64e29ee756f290e7eb047610b567ef04
We were previously failing to send blobs to new content processes, which was a
problem for those processes. But we were also attempting to extract blobs for
new entries that we were serializing after we'd extracted their structured
clone data, and their blob array had been thrown away (which was a problem for
all processes).
This patch fixes both problems.
MozReview-Commit-ID: 3qbAmUTA85g
--HG--
extra : rebase_source : 87ed9356aa23ae83762a887cf12ba1f466e7bf61
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
