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
Creating and populating temporary export objects is fairly expensive. Defining
and then redefining lazy getters is sometimes even more expensive.
Caching the export objects from module imports, and immediately defining
properties from already-imported modules appears to save a considerable amount
of overhead at startup.
MozReview-Commit-ID: 2jR1i0WpIcw
--HG--
extra : rebase_source : d64e3380f290b12a004177be678abad88530bbc5
This is a purely non-functional plumbing change. Instead of passing a
SizeOfState and an nsStyleSizes a bunch of places, we pass an nsWindowSizes,
which contains both of them.
This is a necessary precursor for the next patch.
MozReview-Commit-ID: Ek03wDM50rB
--HG--
extra : rebase_source : 7b05708bd21dc4e3812ea041647fa74bb413d0b9
This is straightforward, with only two notable things.
- `#include "nsXPIDLString.h" is replaced with `#include "nsString.h"`
throughout, because all nsXPIDLString.h did was include nsString.h. The
exception is for files which already include nsString.h, in which case the
patch just removes the nsXPIDLString.h inclusion.
- The patch removes the |xpidl_string| gtest, but improves the |voided| test to
cover some of its ground, e.g. testing Adopt(nullptr).
--HG--
extra : rebase_source : 452cc4a08046a1adb1a8099a7e85a1917de5add8
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is used in ways that rely on the implicit conversion
to |char*|. The patch uses get() and EqualsLiteral() calls to replace the
implicit conversions.
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is only used in ways that nsCStrings can also be used
(i.e. no null checks or implicit conversions to |char*|).
In every case the patch trivially replaces the nsXPIDLCString with an
nsCString. (Also, there are a couple of unused nsXPIDLCString variables that
the patch simply removes.)
This patch moves measurement of ComputedValues objects from Rust to C++.
Measurement now happens (a) via DOM elements and (b) remaining elements via
the frame tree. Likewise for the style structs hanging off ComputedValues
objects.
Here is an example of the output.
> ├──27,600,448 B (26.49%) -- active/window(https://en.wikipedia.org/wiki/Barack_Obama)
> │ ├──12,772,544 B (12.26%) -- layout
> │ │ ├───4,483,744 B (04.30%) -- frames
> │ │ │ ├──1,653,552 B (01.59%) ── nsInlineFrame
> │ │ │ ├──1,415,760 B (01.36%) ── nsTextFrame
> │ │ │ ├────431,376 B (00.41%) ── nsBlockFrame
> │ │ │ ├────340,560 B (00.33%) ── nsHTMLScrollFrame
> │ │ │ ├────302,544 B (00.29%) ── nsContinuingTextFrame
> │ │ │ ├────156,408 B (00.15%) ── nsBulletFrame
> │ │ │ ├─────73,024 B (00.07%) ── nsPlaceholderFrame
> │ │ │ ├─────27,656 B (00.03%) ── sundries
> │ │ │ ├─────23,520 B (00.02%) ── nsTableCellFrame
> │ │ │ ├─────16,704 B (00.02%) ── nsImageFrame
> │ │ │ ├─────15,488 B (00.01%) ── nsTableRowFrame
> │ │ │ ├─────13,776 B (00.01%) ── nsTableColFrame
> │ │ │ └─────13,376 B (00.01%) ── nsTableFrame
> │ │ ├───3,412,192 B (03.28%) -- servo-style-structs
> │ │ │ ├──1,288,224 B (01.24%) ── Display
> │ │ │ ├────742,400 B (00.71%) ── Position
> │ │ │ ├────308,736 B (00.30%) ── Font
> │ │ │ ├────226,512 B (00.22%) ── Background
> │ │ │ ├────218,304 B (00.21%) ── TextReset
> │ │ │ ├────214,896 B (00.21%) ── Text
> │ │ │ ├────130,560 B (00.13%) ── Border
> │ │ │ ├─────81,408 B (00.08%) ── UIReset
> │ │ │ ├─────61,440 B (00.06%) ── Padding
> │ │ │ ├─────38,176 B (00.04%) ── UserInterface
> │ │ │ ├─────29,232 B (00.03%) ── Margin
> │ │ │ ├─────21,824 B (00.02%) ── sundries
> │ │ │ ├─────20,080 B (00.02%) ── Color
> │ │ │ ├─────20,080 B (00.02%) ── Column
> │ │ │ └─────10,320 B (00.01%) ── Effects
> │ │ ├───2,227,680 B (02.14%) -- computed-values
> │ │ │ ├──1,182,928 B (01.14%) ── non-dom
> │ │ │ └──1,044,752 B (01.00%) ── dom
> │ │ ├───1,500,016 B (01.44%) ── text-runs
> │ │ ├─────492,640 B (00.47%) ── line-boxes
> │ │ ├─────326,688 B (00.31%) ── frame-properties
> │ │ ├─────301,760 B (00.29%) ── pres-shell
> │ │ ├──────27,648 B (00.03%) ── pres-contexts
> │ │ └─────────176 B (00.00%) ── style-sets
The 'servo-style-structs' and 'computed-values' sub-trees are new. (Prior to
this patch, ComputedValues under DOM elements were tallied under the the
'dom/element-nodes' sub-tree, and ComputedValues not under DOM element were
ignored.) 'servo-style-structs/sundries' aggregates all the style structs that
are smaller than 8 KiB.
Other notable things done by the patch are as follows.
- It significantly changes the signatures of the methods measuring nsINode and
its subclasses, in order to handle the tallying of style structs separately
from element-nodes. Likewise for nsIFrame.
- It renames the 'layout/style-structs' sub-tree as
'layout/gecko-style-structs', to clearly distinguish it from the new
'layout/servo-style-structs' sub-tree.
- It adds some FFI functions to access various Rust-side data structures from
C++ code.
- There is a nasty hack used twice to measure Arcs, by stepping backwards from
an interior pointer to a base pointer. It works, but I want to replace it
with something better eventually. The "XXX WARNING" comments have details.
- It makes DMD print a line to the console if it sees a pointer it doesn't
recognise. This is useful for detecting when we are measuring an interior
pointer instead of a base pointer, which is bad but easy to do when Arcs are
involved.
- It removes the Rust code for measuring CVs, because it's now all done on the
C++ side.
MozReview-Commit-ID: BKebACLKtCi
--HG--
extra : rebase_source : 4d9a8c6b198a0ff025b811759a6bfa9f33a260ba
nsXPIDLStrings are marked as VOIDED upon initialization. Most of these local
nsXPIDLString variables are immediately set via getter_Copies(), which will
either assign a string value (using Adopt()) or do SetIsVoid(). These can be
trivially converted to nsString, which will get the same treatment.
The patch suitably converts the remaining nsXPIDLString local variable as well.
--HG--
extra : rebase_source : 5fff9f2c6844559198f601853f8db08564add7d5
As our threattype-listname conversion design, "goog-harmful-proto" is allocated
for this new threat type. This threat type is mainly for mobile.
MozReview-Commit-ID: G9GbgmHHHfp
--HG--
extra : rebase_source : 0681fcd9322b94451a86eafe57bf1ccc4b89db30
extra : intermediate-source : 28b0502d9add81beeae58a2c33f9fd5839d4d544
extra : source : 646f02f15131aa98ad37015b0a641304a3271796
Checking this pref to avoid log spam in opt builds, in sandboxes, JS
components, and whatever uses nsFrameMessageManager's dump method.
This does mean that on Windows in an opt build when a debugger is
present a debug string will no longer be printed unless the pref is
set, but I think that is consistent with the non-Windows behavior.
MozReview-Commit-ID: FWLAzBRVhlx
--HG--
extra : rebase_source : cc5669f422729788f1ebc300d4450290913a3055
We should turn on test_localeCompare.js again on Android since we use ICU.
MozReview-Commit-ID: 1H0DsKpWkId
--HG--
extra : rebase_source : d29564bfd20ee6fbc2eadf2f4b80066efc3deef0
extra : histedit_source : 294c17ea1736f196aca7aa969203428e6792625e
This callback is only used in very limited ways, so just require that
the caller pass in the canonical supports pointer, plus the
participant. This probably won't affect performance much.
MozReview-Commit-ID: CsThzFsKyYx
--HG--
extra : rebase_source : 9595b1d75fc45bc5ee6d932a840e98b5d760cb78
All the SizeOf{In,Ex}cludingThis() functions take a MallocSizeOf function
which measures memory blocks. This patch introduces a new type, SizeOfState,
which includes a MallocSizeOf function *and* a table of already-measured
pointers, called SeenPtrs. This gives us a general mechanism to measure
graph-like data structures, by recording which nodes have already been
measured. (This approach is used in a number of existing reporters, but not in
a uniform fashion.)
The patch also converts the window memory reporting to use SizeOfState in a lot
of places, all the way through to the measurement of Elements. This is a
precursor for bug 1383977 which will measure Stylo elements, which involve
Arcs.
The patch also converts the existing mAlreadyMeasuredOrphanTrees table in the
OrphanReporter to use the new mechanism.
--HG--
extra : rebase_source : 2c23285f8b6c3b667560a9d14014efc4633aed51
This patch replaces four functions of the name AssignWithConversion which
are essentially wrappers around CopyASCIItoUTF16 and LossyCopyUTF16toASCII
with direct calls to the latter two functions. The replaced functions are:
void nsCString::AssignWithConversion( const nsAString& aData )
void nsString::AssignWithConversion( const nsACString& aData )
void nsTString_CharT::AssignWithConversion(
const incompatible_char_type* aData,
int32_t aLength = -1);
The last of the three exists inside the double-included nsTString* world and
so describes two functions, giving four in total.
This has two advantages:
* it removes code
* at the call points, it makes clear (from the replacement name) which
conversion is being carried out. The generic name "AssignWithConversion"
doesn't make that obvious -- one had to infer it from the types.
The patch also removes two commented out lines from
editor/composer/nsComposerCommands.cpp, that appear to be related. They are
at top level, where they would never have compiled. They look like
leftovers from some previous change.
--HG--
extra : rebase_source : fb47bf450771c3c9ee3341dd14520f5da69ec4f5
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
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
--HG--
extra : rebase_source : 523fb559f3d71f16be11ae275ab1f6ea3900eff8
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
--HG--
extra : rebase_source : 2f2bc11d0123fd7e14c2a5e716a764e7ab8ded46
Because it's just a wrapper for js_free().
Furthermore, JS_smprintf() and friends return a JS::UniqueChars, which is also
wired up to free with js_free(). So having the indirection via
JS_smprintf_free() obfuscates things.
--HG--
extra : rebase_source : 1db80199dc801a2684fffe2a5fd5349a42c6941b
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
--HG--
extra : rebase_source : e5b295a498caf76e60efec4d174e558e9e55d77b
extra : histedit_source : dd683966b30090b5702264c2903e6050be0e4137
Since we now usually load modules from one of the startup caches, we usually
have no need to ever actually create a channel in order to load them.
Resolving the URIs directly is much cheaper in the normal case.
MozReview-Commit-ID: 8W8RMHRnyBa
--HG--
extra : rebase_source : 073ae92c3dc53e86084c1daa1ccfe720ade634c6
extra : histedit_source : cf6cc2b025a839e39aa48bf412ee3a273b549bbe
The Chromium IPC histogram code used the StatisticsRecorder object for storage.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
Consequently we need to rewrite this storage, which means StatisticsRecorder is not used anymore.
MozReview-Commit-ID: 1LC7YubpKaD
XPCOMUtils.generateQI is called a lot, and the current implementation is
especially inefficient. It relies on calling the stringification slow path
twice for each interface ID, which begins to add up fast given how often it's
called.
MozReview-Commit-ID: 2O87wBVMA2G
--HG--
extra : rebase_source : b3d43fbe77990e82702491a58d59c4e439d3d2f8
The Chromium IPC histogram code used the StatisticsRecorder object for storage.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
Consequently we need to rewrite this storage, which means StatisticsRecorder is not used anymore.
MozReview-Commit-ID: 1LC7YubpKaD
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
--HG--
extra : rebase_source : ef7237953404fd1b75e8e1118b9fc4e2235ff187
The Chromium IPC histogram code used the StatisticsRecorder object for storage.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
Consequently we need to rewrite this storage, which means StatisticsRecorder is not used anymore.
MozReview-Commit-ID: 1LC7YubpKaD
It is only called in a single place, and can't be called from JS, so
inline it and eliminate it.
MozReview-Commit-ID: DWfyfoO5Zht
--HG--
extra : rebase_source : 8a44719af22a4d8724449d6225f4bdd119d648c8
Also, one unused include of nsIProgrammingLanguage, which is unrelated.
MozReview-Commit-ID: LJf2NSwmaYG
--HG--
extra : rebase_source : 63dfca9185535dbfa695cf2f383d81a14ce423c0
The main reason to not do this would be performance (avoiding the
addref/release), but there are two main mitigating factors:
1) All calls to UnwrapReflectorToISupports that pass in a Web IDL object
already do the addref (and in fact QI). So this only affects the
XPCWrappedNative case.
2) The vast majority of the callers proceed to QI on the pointer anyway, and a
second addref is cheap; it's the first addref after a CC that can be
expensive on a cycle-collected object.
Going through the changes one by one:
* In GlobalObject::GetAsSupports, we do have a change that slightly slows down
precisely in the XPCWrappedNative global case. That's the message managers
and the backstagepass. And this really only affects calls to Web IDL statics
from those globals.
* In UnwrapArgImpl we're talking about a Web IDL method taking an "external
interface" type, and the UnwrapReflectorToISupports call is immediately
followed by QI anyway.
* In UnwrapXPConnectImpl we're talking about the case when we have a
non-WebIDL-object implementation of a Web IDL interface. Again, this is the
message manager globals, for EventTarget. And we have a QI call immediately
after the UnwrapReflectorToISupports.
* In the generated HasInstance hook for EventTarget we will be slightly slower
when the LHS of the instanceof is an XPCWrappedNative. And not much slower,
because again there's an immediate QI.
* In InstallXBLField we're never going to have an XPCWrappedNative as thisObj;
it's always an Element in practice. So this is no more expensive than before.
* In sandbox's GetPrincipalOrSOP we now have an extra addref. But it was
followed by various QIs anyway.
* In XPCConvert::JSValToXPCException we have an extra addref if someone throws
an XPCWrappedNative, which is fairly unlikely; our actual Exception objects
are on Web IDL bindings. Plus we have an immediate QI.
* In xpc::HasInstance we have an extra addred if the LHS of instanceof is an
XPCWrappedNative. But, again, there's an immediated QI after the
UnwrapReflectorToISupports.
* In xpcJSWeakReference::Init we are likely doing an extra addref, but again
immediately followed by QI.
I think it's worth making this change just to remove the footgun and that the
perf impact, if any, is pretty minimal.
Most of these changes are just replacements of GetNativeOfWrapper with
UnwrapReflectorToISupports, which is all it did under the hood.
The other changes are as follows:
* In nsDOMClassInfo, we really care whether we have a window, so we can just
UNWRAP_OBJECT to the Window interface, since Window is always on Web IDL
bindings now. Also, the weird compartment check hasn't been needed ever since
GetNativeOfWrapper stopped returning things off the passed-in object's
prototype chain (Firefox 22, bug 658909).
* The only use of do_QueryWrapper was to get a Window in nsDocument; again we
can UNWRAP_OBJECT.
* In XPCJSRuntime, we again just want to check for a Window, so UNWRAP_OBJECT.
The existing code uses various intermediate objects, but the only
thing they are used for now is to figure out if the compartment we're
in has the system principal or not, so just compute that directly.
MozReview-Commit-ID: FMoWfAX8rGW
--HG--
extra : rebase_source : 385ab0e10a0c719155c48e3822e7844434f417f8
xpcshell has a custom directory provider that is passed in when XPCOM is
initialized. XPCOM holds a reference to this directory provider, and
said reference is not released until XPCOM is shutdown. Unfortunately,
the lifetime of the directory provider was not scoped properly, so it
would actually be destructed prior to shutting down XPCOM, resulting in
a stack use-after-free.
To avoid this problem, we need to move the provider so that its lifetime
outlives the call to both XPCOM init and shutdown.
Removing the redundant unwrapping improves ~15% for the micro benchmark (bug
1348095 comment 3) on my desktop. Replace the parameter jsWrapper of
resolveOwnProperty() because it is not used.
MozReview-Commit-ID: ULHX8vyMrZ
--HG--
extra : rebase_source : b76e688f53722cfd24466668b68043366f25e917
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
This patch gives some structure and order to the profiler's API.
It also renames AutoProfilerRegister as AutoProfilerRegisterThread, to match
profiler_register_thread().
This patch reduces the differences between builds where the profiler is enabled
and those where the profiler is disabled. It does this by removing numerous
MOZ_GECKO_PROFILER checks.
These changes have the following consequences.
- Various functions and classes are now defined in all builds, and so can be
used unconditionally: profiler_add_marker(), profiler_set_js_context(),
profiler_clear_js_context(), profiler_get_pseudo_stack(), AutoProfilerLabel.
(They are effectively no-ops in non-profiler builds, of course.)
- The no-op versions of PROFILER_* are now gone. The remaining versions are
almost no-ops when the profiler isn't built.
--HG--
extra : rebase_source : 8fb5e8757600210c2f77865694d25162f0b7698a
This is useful for legacy addons as we increasingly lockdown filesystem access
in content processes.
MozReview-Commit-ID: AZbsSFpbIvt
--HG--
extra : rebase_source : 56dfe91ac9fbeb0bd48dc8a2f87ed6038e7521cc
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
--HG--
extra : rebase_source : c5f104381187cf55a171916364fba527c44b4172
This helper is already being used in the script preloader, and encapsulates
all of the memory mapping and RAII logic used to do the same in the component
loader. Reusing it there allows us to remove a lot of redundant code.
This is applied on top of the patches for bug 989373 in order to avoid
conflicts.
MozReview-Commit-ID: AJ26qV4JLci
--HG--
extra : rebase_source : 88a338ef9a88ff0b775f3f31600f32892b932940
extra : amend_source : 8312eef5078b2782c872ae964c23c2adb54f5ef7
