Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
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
--HG--
extra : rebase_source : 9bd5d884e32cfa59c022edb00078aac050acb20b
This patch also ensures that we won't accidentally try stopping slow scripts
when we're shutting down the watchdog manager.
MozReview-Commit-ID: EMb0enfivd8
--HG--
extra : rebase_source : b27205c4d593caa1c33534591686e85fba9f0d41
The last argument is always null, so we don't need this function any more.
MozReview-Commit-ID: 5YWMO9ywZK3
--HG--
extra : rebase_source : 56bce2611135bb1b30e7f8ad763e13f112d2395f
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: DbTW5Bhd9E1
--HG--
extra : rebase_source : b27f666e5ca832d814fb6846208474e1ec66e5f4
extra : source : 9ff4e11402a9a43ed90298a9c354b0164cf9414f
XPCOM's string API doesn't have the notion of a "null string". But it does have
the notion of a "void string" (or "voided string"), and that's what these
functions are returning. So the names should reflect that.
--HG--
extra : rebase_source : 4e3f982e0873877174a08a25413595ff66f7d20e
nsIHandleReportCallback, typedef of nsIMemoryReporterCallback, has been the
preferred name for a long time and is used in most places. This patch removes
nsIMemoryReporterCallback.
--HG--
extra : rebase_source : c675076b4f98d93d96235dad890e31e0b0e6c277
We don't have access to an appropriate context to create the dead wrapper in
when the callback is nuked, so instead, this patch creates a new dead wrapper
in the caller compartment each time the property is accessed. This is the same
behavior we'd get when trying to re-wrap a cross-compartment dead wrapper, so
it's consistent with the way we handle these situations elsewhere.
MozReview-Commit-ID: 3cMeR4z8EOe
--HG--
extra : rebase_source : 7e8cf4a195ef64deb7677ce4ac9818d342815667
Also, MOZ_XPCTOOLS does not appear to be a thing any more.
MozReview-Commit-ID: 99BR9rl4EnD
--HG--
extra : rebase_source : 3712b7b2b180b583ca761cdc5d6ddf17728e8b74
The script precompiler needs to begin its work very early in the startup
process in order to be effective. At the moment, this means before user
preferences are loaded. It also needs to be able to compile scripts into
the shared JSM global when that's in use, in order to avoid unnecessary script
clones.
Since we can't know whether global sharing is enabled by that point, instead,
we just always compile module scripts into the shared module global rather
than the XPC compillation scope.
This also changes the global sharing tests to make a failure to respect the
user preference value a fatal error.
MozReview-Commit-ID: G0NkSOl2vU9
--HG--
extra : rebase_source : 4b5e1b10c14dd5cc6609bc589310d12b44f830f5
When using the subscript loader with JSM global sharing, it was possible
that subscript would pollute the global of all JSMs in the sharing.
MozReview-Commit-ID: 1ah5JUAZwBA
--HG--
extra : rebase_source : 45a3974cb80ede0cb3beea92f895679c5ea7aa4b
We want to be able to store scripts compiled with or without
non-syntactic support in cache when we toggle JSM global sharing. In
current code this script is cloned on execution, but with JSM global
sharing we have would hit assertions.
MozReview-Commit-ID: 2pVTTxLpx6S
--HG--
extra : rebase_source : b123de20f216161c408bba75c8c0fd81be0508df
When using the subscript loader with JSM global sharing, it was possible
that subscript would pollute the global of all JSMs in the sharing.
MozReview-Commit-ID: 1ah5JUAZwBA
--HG--
extra : rebase_source : 202904e30b582c788ec440c406607ba98b8836e6
We want to be able to store scripts compiled with or without
non-syntactic support in cache when we toggle JSM global sharing. In
current code this script is cloned on execution, but with JSM global
sharing we have would hit assertions.
MozReview-Commit-ID: 2pVTTxLpx6S
--HG--
extra : rebase_source : 5913a43a2dfddf74187f08ab9c53babe377bd706
This also introduces JS::GetObjectRealmOrNull, which returns an object's realm,
or null if the object is a cross-compartment wrapper. In the new order,
wrappers can't have realms, since they must be shared across all realms in a
compartment. We're introducing this new function early (even though it's
*currently* possible to assign a realm to wrappers) in order to see in
advance if the possibility of returning null will cause problems.
(It looks like it won't.)
--HG--
extra : rebase_source : e55ebbbc4edf2a18ce267198928246592060e339
extra : source : d6bfce1187aa13dbfab03f9566ff7b05b6705e70
When using the subscript loader with JSM global sharing, it was possible
that subscript would pollute the global of all JSMs in the sharing.
MozReview-Commit-ID: 1ah5JUAZwBA
--HG--
extra : rebase_source : 5fecf7dc61019431d67bcee4199e40a8278c8c64
This class doesn't have anything to do with __exposedProps__ any more,
so give it a more descriptive name. We'd still like to remove it
entirely eventually.
MozReview-Commit-ID: 87KCpG6f8rI
--HG--
extra : rebase_source : 98a51a6af0fc8446dbcd8efa083d6c79286279d3
This patch gently removes support for __exposedProps__ by changing
ExposedPropertiesOnly::check() to always return false, while still
failing silently in deny for some kinds of access.
The tests that I changed all involve testing the behavior with
__exposedProps__. I adjusted them to expect it to fail, or to adjust
the error message they get when they fail. That seemed better than
deleting them entirely.
Note that test_bug1065185.html had a bug, so that it never executed
the first case. I fixed that, and then fixed up the test to work when
__exposedProps__ is not supported.
This also removes various bits of the test framework that use
__exposedProps__, but don't actually need to.
MozReview-Commit-ID: 8fvkAmITmXY
--HG--
extra : rebase_source : ef7e2c55adc12511f17f3865ebb46c343875f0b3
In the new order, it will be a compartment-level bit rather than a
realm-level bit, so it does not belong on the Scope.
--HG--
extra : rebase_source : 44aa4620f7fd7f8d253c8c7f09bf8c97c00ff061
extra : source : 5a9c01720d7929e43aa70341d3821bfaa2479592
The entire purpose of this patch is to support accessing this bit from
WrapperFactory (see the last hunk) without going through a particular
scope.
--HG--
extra : rebase_source : d2952e981f4b277e6ca565077c6e6d18c69c8df5
If you pass a string from script to an IDL method that takes an nsIAtom,
XPConnect will automagically atomize the string for you.
But nsIAtom is no longer scriptable (see the blockers for bug 1392883,
especially bug 1396694). So the code to convert can be removed.
--HG--
extra : rebase_source : af85fa48c1988348d3a9a81b05ed43403d3b730a
This tests both that the settings have the desired effect and that switching
between sharing enabled and sharing disabled without a startup cache flush
does not cause any issues.
Tests for user pref changes are currently non-fatal, since they're known not
to work reliably.
MozReview-Commit-ID: 1ZFwyiNf3da
--HG--
extra : rebase_source : c38bd92d2137c90f8c4d202b7009612b45ff4be9
User preference changes currently don't reliably take effect before component
loader initialization, which means they can't be used to write reliable tests.
Environment variables don't have this problem, so adding an environment
variable override makes testing much easier. It's also fairly convenient
during development, when we need to switch between different configurations
for testing.
MozReview-Commit-ID: 8PufRQNRnoU
--HG--
extra : rebase_source : c5ca2f3cb18a8398c95bbbf86e2cd27430f5161a
Scripts for use in shared globals need to be compiled for non-syntactic
scopes, while scripts for standalone globals should be compiled as global
scripts for better performance.
Since the startup cache and script preloader store scripts as they were
compiled in the last session, when global sharing settings may have been
different, it can lead to a mismatch, and a crash, due to loading the wrong
type of script.
Using a separate cache path for each type of script fixes this problem, since
it ensures that the cached script will always be of the type we expect.
MozReview-Commit-ID: DnNb2Xi6KeL
--HG--
extra : rebase_source : d2474d1da3f8e1066c21a7c65693ea09ec5b8074
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
--HG--
extra : rebase_source : 93f639022375dd3f0b8e06533e829ce4089d46b7
I added the predicate so people can't just start grabbing the loader
global and doing scary things with it.
MozReview-Commit-ID: HzPtMzEm0Ln
--HG--
extra : rebase_source : a0bed5901e54dd1e64c7ef233cd58cdfb1f136d4
This patch adds a preference jsloader.shareGlobal that makes it so
that JSMs share a single global, in order to reduce memory usage. The
pref is disabled by default, and will be enabled in a later bug. Each
JSM gets its own NonSyntacticVariablesObject (NSVO), which is used for
top level variable bindings and as the value of |this| within the JSM.
For the module loader, the main change is setting up the shared
global, and the NSVO for each JSM. A number of files are blacklisted
from the shared global, because they do things to the global that
would interfer with other JSMs. This is detailed in
mozJSComponentLoader::ReuseGlobal().
MozReview-Commit-ID: 3qVAc1c5aMI
--HG--
extra : rebase_source : fe7e2672be8d09d6b7cec25e08cd464ff3cd6573
This are some unit tests to track regressions in the environment
behavior exposed to embeddings for various javascript loaders inside
Gecko.
MozReview-Commit-ID: 8pn56Skwbat
These flags don't guarantee that the getter and setter functions are defined.
MozReview-Commit-ID: GBcoRYoKHqL
--HG--
extra : rebase_source : 1234ec91cf05566a3130360b152bf2cb986ec1c3
Going through the extension policy service rather than using
WebExtensionPolicy objects directly adds a lot of unnecessary overhead to
common operations on extension principals, and also makes the code more
complicated than it needs to be.
We also use weak references to policy objects here, since principals should
ideally lose as much of their elevated privileges as possible once the
extension instance that created them has been destroyed (which is something we
couldn't handle easily when we simply tracked ID strings).
MozReview-Commit-ID: KDNvVdvLkIt
--HG--
extra : rebase_source : 1b567919d2461bd0315d1a7d89f330cbd585f579
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
--HG--
extra : rebase_source : a5988ff770888f901dd0798e7717bcf6254460cd
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
--HG--
extra : rebase_source : 24ad4a54cbd170eb04ded21794530e56b1dfbd82
1. Make nsINamed queriable on WrappedJSHolder.
2. Identify callers via |Cu.generateXPCWrappedJS(aCallback).QueryInterface(Ci.nsINamed).name|.
--HG--
extra : amend_source : 5d4201059f66e46c869c30a963921b6f7b91c389
This might be prematurely optimized as it uses two lists (one list of active
contexts and one list of inactive contexts) but I was really attracted by the
idea of being able to answer questions like "is any context active" by only
looking at a single context and not having to iterate the whole list every
time we needed to do anything.
It is really important that nobody touches any of the timestamps (or the
mActive member) outside of the Watchdog lock. I thought about trying to
encapsulate that data in its own class, but that felt like overkill. Let me
know if you disagree.
There are still a couple of uses of XPCJSContext::Get that probably need to be
stamped out, but I think doing so will depend on the details of how we map
JSContexts to XPCJSContext (and XPCJSRuntimes). I think that should wait for a
separate bug.
MozReview-Commit-ID: 9UZlh7Jutne
--HG--
extra : rebase_source : 039b50bc70547b03bc0724435de0a10a29fcf85e
The current code assumes it can store data about "the" XPCJSContext on the
WatchdogManager singleton. Once we have more than one XPCJSContext running
around, that won't be possible. This moves the needed data onto the
XPCJSContext itself and gives the WatchdogManager the proper context to
operate on.
MozReview-Commit-ID: AxyFKp9LmH3
--HG--
extra : rebase_source : 113e3b8986563016d43b25e753bde61f7af49291
This might be prematurely optimized as it uses two lists (one list of active
contexts and one list of inactive contexts) but I was really attracted by the
idea of being able to answer questions like "is any context active" by only
looking at a single context and not having to iterate the whole list every
time we needed to do anything.
It is really important that nobody touches any of the timestamps (or the
mActive member) outside of the Watchdog lock. I thought about trying to
encapsulate that data in its own class, but that felt like overkill. Let me
know if you disagree.
There are still a couple of uses of XPCJSContext::Get that probably need to be
stamped out, but I think doing so will depend on the details of how we map
JSContexts to XPCJSContext (and XPCJSRuntimes). I think that should wait for a
separate bug.
MozReview-Commit-ID: 9UZlh7Jutne
--HG--
extra : rebase_source : a927511fbf5a7bbdb75f616b751ec3fb51e76903
The current code assumes it can store data about "the" XPCJSContext on the
WatchdogManager singleton. Once we have more than one XPCJSContext running
around, that won't be possible. This moves the needed data onto the
XPCJSContext itself and gives the WatchdogManager the proper context to
operate on.
MozReview-Commit-ID: AxyFKp9LmH3
--HG--
extra : rebase_source : 113e3b8986563016d43b25e753bde61f7af49291
