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
Also adds a mozilla/ResultExtensions.h header to define the appropriate
conversion functions for nsresult and PRResult. This is in a separate header
since those types are not available in Spidermonkey, and this is the pattern
other *Extensions.h headers follow.
Also removes equivalent NS_TRY macros and WrapNSResult inlines that served the
same purpose in existing code, and are no longer necessary.
MozReview-Commit-ID: A85PCAeyWhx
This allows MOZ_TRY and MOZ_TRY_VAR to be transparently used in XPCOM methods
when compatible Result types are used.
Also removes a compatibility macro in SimpleChannel.cpp, and an identical
specialization in AddonManagerStartup, which are no longer necessary after
this change.
MozReview-Commit-ID: 94iNrPDJEnN
Off-thread parse tasks depend on the memory allocated by the main-thread
script preloader, so that memory needs to be kept alive until they finish. In
normal use cases, this is guaranteed, but when the browser shuts down very
quickly (as sometimes happens in tests), or we invalidate the startup caches
in the middle of the startup process, they can sometimes be freed too early.
MozReview-Commit-ID: GQmkVbWgTH9
In general, we always want to compile with lazy source whenever we intend to
store code in the startup bytecode cache. Currently, we only do so when the
main StartupCache is available (which is only in the parent process), even if
we'll be storing code in the ScriptPreloader cache.
The main side-effect of this is that scripts which are used in a content
process do not use lazy source, but *do* use lazy parsing. And since we need
to clone pre-loaded scripts into their target compartment before executing, we
end up eagerly compiling those lazy functions on the main thread as soon as we
execute the script, in order to clone them. And this causes two side-effects
of its own:
1) It's terrible for startup performance.
2) It creates new scope chains which didn't exist when the clone began, and
which are likely responsible for bug 1367896.
MozReview-Commit-ID: 6lZLb68zitp
The current logic is fairly hard to follow, and fails to account for changes
in the set of processes a script needs to be executed in when deciding whether
to write a new cache file. These changes simplify that logic considerably,
increase the chances that we'll correctly pre-decode a script that's needed in
a given process during startup.
MozReview-Commit-ID: BvqjKU8FDHW
