initialProcessData has the unfortunate side-effect of sending an entire copy
of all of its data to all content processes, and eagerly decoding it. For the
extension framework, this means that we wind up loading an entire copy of all
of our schema data, and of every extension's manifest and locale data, into
every process, even if we'll never need it.
The sharedData helper allows us to store an encoded copy of that data in a
shared memory region, and clone it into the current process only when we need
it, which can be a significant savings. For screenshots alone, it saves about
15K on locale and manifest data per content process, plus the size we save on
not copying schema data.
MozReview-Commit-ID: KkIOoLsBd99
I was hoping to avoid supporting blobs here, but some parts of the
WebExtensions framework rely on being able to store Blobs in
initialProcessData, and can't be migrated without adding blob support.
This patch adds an ordered array of BlobImpls for all extant keys, clones them
to all child processes when updating the serialized maps, and initializes
StructuredCloneData instances with indexes into the combined array.
MozReview-Commit-ID: IdSv5FHbPbE
This is the first basic implementation of a shared-memory key-value store for
JS message managers. It has one read-write endpoint in the parent process, and
separate read-only endpoints for each child-process message manager.
Changes to the parent endpoint are broadcast to the children as snapshots.
Each snapshot triggers a "change" event with a list of changed keys.
It currently has the following limitations:
- It only supports basic structured clone data. There's no support for blobs,
input streams, message ports... Blob support will be added in a follow-up
patch.
- Changes are currently only broadcast to child endpoints when flush() is
explicitly called in the parent, or when new child processes are launched.
In a follow-up, this will be changed to automatically flush after changes
when the event loop is idle.
- All set operations clone their inputs synchronously, which means that
there's no trivial way for callers to batch multiple changes to a single key
without some additional effort. It might be useful to add a
delayed-serialization option to the .set() call in a follow-up, for callers
who are sure they know what they're doing.
MozReview-Commit-ID: IM8a3UgejXU
This class allows one read-write copy of a map in the parent process to share
data with multiple read-only copies in child processes. The maps only hold
onto data as structured clone blobs, and deserialize them each time a key is
read.
This commit only provides the bare-bones data structures. Follow-ups will add
bindings, change events, and automatic flushes.
MozReview-Commit-ID: LimwfmFBNOi
This adds reporting of nsMemoryReporterManager's internals. Currently we just
report the weak and strong ref hashtables which have shown up in DMD reports.
The new entry is '/explicit/memory-reporter-manager'.
Also change PlacesUtils.history.removeVisitsByFilter to be able to remove by transition type.
MozReview-Commit-ID: Bkiv0ScUi07
Differential Revision: https://phabricator.services.mozilla.com/D2056
The JPEG decoder will currently only post an invalidation when it has
processed all of the rows it is able to. If it is has all the data, that
means it must fully decode before invalidating. This causes very large
JPEGs to appear in large chunks which feels janky compared to slowly
appearing row by row with the refresh tick. With WebRender, it also
allows us to upload less data per frame update which can be another
source of jank.
Automatic update from web-platform-testsSplit up WebCryptoAPI/derive_bits_keys/ with `variant`
Also use .any.js.
Fixes#11203.
--
wpt-commits: 864cba25d0ac3d2f49e851623370f565ca293cbe
wpt-pr: 11204
Summary:
It looks like we need a clobber in order for the build system to properly find
gyp at its new location.
Reviewers: chmanchester
Tags: #secure-revision
Bug #: 1371485
Differential Revision: https://phabricator.services.mozilla.com/D2035
