We do this because we will be introducing more privileged content processes
and we want to be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D30274
We do this because we will be introducing more privileged content processes
and we want to be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D30274
There are currently some odd circumstances where we deadlock waiting for the
background save thread to finish while it is blocked on sync dispatch to the
main thread during shutdown.
There were existing workarounds to prevent this, which tried to synchronously
complete the main thread work required by the background thread at the start
of shutdown, and some fallback anti-deadlock assertions to catch any remaining
corner cases, but apparently Fennec has corner cases of its own that we didn't
anticipate.
This patch takes the more straightforward route of using an async shutdown
blocker, which allows the async shutdown service to safely spin the event loop
until the save completes, rather than an independent monitor loop, which does
not.
It also fixes a potential data race where the save thread could clear its
mSaveThread member before NS_NewNamedThread returned, running afoul of
nsCOMPtr sanity checks.
Differential Revision: https://phabricator.services.mozilla.com/D28127
In bug 1264235 we have some indication that observed bugs with the
startup cache might have been resolved, but we don't really know
until we collect data. Collecting these stats will give us the
ability to have more certainty that the startup cache is functioning
correctly in the wild.
Differential Revision: https://phabricator.services.mozilla.com/D19573
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
We only run process scripts once per process, so there's no need to compile
them for the compilation scope, or to keep a separate cloned copy alive for
the length of the session.
This patch changes the caching behavior of message managers to compile
single-use scripts directly for the target global, and avoid caching them for
the rest of the session. It also changes the preloader to drop references to
these scripts after they've been executed and/or encoded, as appropriate.
MozReview-Commit-ID: EfKo2aYbBxl
Summary:
This patch adds the infrastructure to move Activity Stream (about:newtab, about:home,
and about:welcome) into its own special content process - the privileged content
process. This feature of running Activity Stream in the privileged content process
is disabled by default. (See "browser.tabs.remote.separatePrivilegedContentProcess"
preference.) We can deal with other about: pages in a follow-up.
Reviewers: mconley
Tags: #secure-revision
Bug #: 1469072
Differential Revision: https://phabricator.services.mozilla.com/D1731
MozReview-Commit-ID: 5gIrP4LxcIt
Originally, the ScriptPreloader stopped recording and wrote its cache when the
browser-delayed-startup-finished notification fired for the first window, but there
are other scripts (both in the content and WebExtension processes) that might run
soon after that we also want to cache.
This patch still makes the parent process stop recording scripts after
browser-delayed-startup-finished, but only prepares and writes the cache
once browser-idle-startup-tasks-finished fires, when it is much more likely
that the content and WebExtension caches are ready to go.
MozReview-Commit-ID: KiBEVvuqQkA
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
The URLPreloader's initialization code accesses the Omnijar cache off-main
thread. It can do so safely only as long as the main thread is blocked, or
running code which is guaranteed never to touch Omnijar, while its critical
section runs.
While that was guaranteed for previous versions of the code, some invariants
changed when we began using the component loader's shared global for initial
compilation. Once the global is created, we can safely use it to initialize
compilation. But creating the global invokes a large amount of Gecko code,
some of which touches Omnijar in the process.
MozReview-Commit-ID: 48WoIZtGPTo
When we pre-compile scripts for a different global than they are eventually
executed in, we need to clone them into the new global before we can execute
them, which can be expensive. This also prevents us from using lazy parsing,
since lazy functions are currently eagerly compiled when cloned.
Since the vast majority of the scripts compiled by the preloader are executed
in the shared modules scope, initially compiling them there removes a lot of
startup overhead. For the few that aren't, we don't lose anything by compiling
them in the shared module global, but we also don't gain anything over
compiling them in the XPConnect compilation scope.
MozReview-Commit-ID: CEh42BmIMhL
