This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Like in case of bug 1506534, this telemetry is sampled periodically every time 2GB of data is written to the cache, i.e. when the cache was used for some time and there is a chance that its content has changed significantly.
Differential Revision: https://phabricator.services.mozilla.com/D29678
--HG--
extra : moz-landing-system : lando
Whenever a cache entry is accessed during a document load, eTLD+1 of the top level document is added to the entry's metadata. Number of accessing sites is also stored in cache index. So we know how many copies of each entry would we have if we did a first party isolation without data deduplication. The telemetry is sent every time we write 2GB to the cache and then the data is reset. Telemetry report ID is an identifier of the telemetry cycle and it's used to invalidate eTLD+1 hashes in all cache entries.
Differential Revision: https://phabricator.services.mozilla.com/D26425
--HG--
extra : moz-landing-system : lando
This patch adds content-type to metadata in cache entry and it is then propagated down to the cache index.
Differential Revision: https://phabricator.services.mozilla.com/D23504
--HG--
extra : moz-landing-system : lando
Maximum size of elements in metadata is 64kB, the rest (URL, hashes and few uint32_t members) should normally fit into 1kB, so I set new high value of NETWORK_CACHE_METADATA_SIZE_2 to 65kB. With 66 buckets each bucket should be exactly 1kB wide.
NETWORK_CACHE_METADATA_FIRST_READ_SIZE doesn't provide any useful information and this patch removes the probe.
Do not report malloc size of CacheIOThread::mThread, because it can be reported by ThreadsReporter.
--HG--
extra : rebase_source : b077f80a82c5df70f1b3f267f7718f1ad7f94ea1
This patch changes all size limits in CacheObserver to kilobytes. The same unit is used at most places when checking these limits. This avoids uint32_t overflow when converting to bytes and back.
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
IDLE markers help with categorizing threads in the profiler UI.
_SLEEP makes the profiler spend less time sampling threads that haven't changed.
Differential Revision: https://phabricator.services.mozilla.com/D10815
--HG--
extra : moz-landing-system : lando
In the current code there are 3 main issues:
1. nsFileStream is not really thread-safe. There is nothing to protect the
internal members and we see crashes.
2. nsPipeInputStream doesn't implement ::Seek() method and that caused issues
in devtools when a nsHttpChannel sends POST data using a pipe. In order to fix
this, bug 1494176 added a check in nsHttpChannel: if the stream doesn't
implement ::Seek(), let's clone it. This was an hack around nsPipeInputStream,
and it's bad.
3. When nsHttpChannel sends POST data using a file stream, nsFileStream does
I/O on main-thread because of the issue 2. Plus, ::Seek() is called on the
main-thread causing issue 1.
Note that nsPipeInputStream implements only ::Tell(), of the nsISeekableStream
methods. It doesn't implement ::Seek() and it doesn't implement ::SetEOF().
With this patch I want to fix point 2 and point 3 (and consequentially issue 1
- but we need a separate fix for it - follow up). The patch does:
1. it splits nsISeekableStream in 2 interfaces: nsITellableStream and
nsISeekableStream.
2. nsPipeInputStream implements only nsITellableStream. Doing this, we don't
need the ::Seek() check for point 2 in nsHttpChannel: a simple QI check is
enough.
3. Because we don't call ::Seek() in nsHttpChannel, nsFileStream doesn't do I/O
on the main-thread, and we don't crash doing so.
This patch changes the way we set and handle the preferred alternate data type.
It is no longer just one choice, but a set of preferences, each conditional
on the contentType of the resource.
For example:
var cc = chan.QueryInterface(Ci.nsICacheInfoChannel);
cc.preferAlternativeDataType("js-bytecode", "text/javascript");
cc.preferAlternativeDataType("ammended-text", "text/plain");
cc.preferAlternativeDataType("something-else", "");
When loaded from the cache, the available alt-data type will be checked against
"js-bytecode" if the contentType is "text/javascript", "ammended-text" if the contentType is "text/plain" or "something-else" for all contentTypes.
Note that the alt-data type could be "something-else" even if the contentType is "text/javascript".
The preferences are saved as an nsTArray<mozilla::Tuple<nsCString, nsCString>>.
Differential Revision: https://phabricator.services.mozilla.com/D8071
--HG--
extra : rebase_source : eb4961f05a52e557e7d2d986d59e0a2cf18a3447
extra : source : dd1c31ea78c2b15d14750d137037a54d50719997
Michal Novotny
Nicholas Nethercote
Sylvestre Ledru
Andrea Marchesini
Bogdan Tara
Cosmin Sabou
Honza Bambas
Gurzau Raul
Valentin Gosu
Luke Wagner
Boris Zbarsky
Ehsan Akhgari
Michal Novotny
Gerald Squelart
Gabriele Svelto