The path service was created to allow us to track resources that were part of
legacy add-ons, and to map URIs ponting to those resources to add-on IDs, so
that we could apply special behavior to them.
We have better ways to track resources belonging to WebExtensions, so this
code does not benefit them in any significant way.
The only remaining legacy extensions are system add-ons, which we control, and
do not need the path service in order to track.
MozReview-Commit-ID: BKXkcaM7jJx
We're seeing startup crashes which point to data corruption in the source of
the AsyncShutdown component and module, but it's unclear whether the source of
this corruption is on disk, in memory, or in XDR data.
This change annotates crash reports with the contents of those files, so that
we can compare the actual source with the corrupted values in the generated
errors, and narrow down the source of the corruption.
MozReview-Commit-ID: 7p8y73XUGLK
We're seeing startup crashes which point to data corruption in the source of
the AsyncShutdown component and module, but it's unclear whether the source of
this corruption is on disk, in memory, or in XDR data.
This change annotates crash reports with the contents of those files, so that
we can compare the actual source with the corrupted values in the generated
errors, and narrow down the source of the corruption.
MozReview-Commit-ID: 7p8y73XUGLK
Looking up and copying exported properties each time a module is loaded is
fairly expensive at the best of times. It's even more expensive when we only
want to export a subset of symbols, which generally requires creating a
temporary object to hold the exports, or fetching them directly from the
returned global.
Aside from making the general case a bit faster, storing exports on an object
allows us to optimize lazy module imports by fetching imported symbols
directly from the exports object with very little additional overhead.
MozReview-Commit-ID: C9PGoXPNmsh
mozJSComponentLoader is created using XPCOM. However, you can only
call it once or it'll crash. This patch fixes that by using a
singleton macro.
MozReview-Commit-ID: Bq2k7nv9dKA
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
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
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
Using the unmolested module location string as the cache key removes a huge
chunk of overhead when loading cached modules.
This also ensures that multiple URLs are not used to load the same module,
which would result in it being loaded more than once in the new regime
MozReview-Commit-ID: BAWoOJQSTc1
People only use these methods via Cu, so remove them from this
interface. Also, ban anybody from implementing this interface in JS
(though I can't imagine anybody trying), and eliminate a variant of
mozJSComponentLoader::ImportInto that is never called.
MozReview-Commit-ID: Kok5ksXiK5a
People only use these methods via Cu, so remove them from this
interface. Also, ban anybody from implementing this interface in JS
(though I can't imagine anybody trying), and eliminate a variant of
mozJSComponentLoader::ImportInto that is never called.
MozReview-Commit-ID: Kok5ksXiK5a
SetLocationForGlobal is called on globals created for JSMs to give
them a nice name for about:memory. Right now this is done in
ImportInto and LoadModule, but I think it makes more sense to set the
name once, right after the global is created. Calling GetSpec on aURI
seems to return the same spec we'd use in these two call sites. This
change makes it easier to label the shared JSM global nicely in bug
1186409.
MozReview-Commit-ID: 5qKMbzLEiuG
This makes the code a little nicer to read, and means there will be less code churn
if we later add back the ability to share globals.
The holder also gets changed to an actual JS object.
mLoaderGlobal is always null, but the simplification for that will be
made in a later patch.
MozReview-Commit-ID: 7Qg7JSgIxxm
Removing support for this preference means that mReuseLoaderGlobal
will always be false, which lets us eliminate that field, and remove a
lot of code.
This also means that false is always passed to
PrepareObjectForLocation for aReuseLoaderGlobal.
ReadCachedFunction is no longer used, so it is deleted.
MozReview-Commit-ID: 5JD24EYVcQf
They are kept around for the sake of the standalone glue, which is used
for e.g. webapprt, which doesn't have direct access to jemalloc, and thus
still needs a wrapper to go through the xpcom function list and get to
jemalloc from there.
