In two places we fail to check if we successful obtained the crash reporter
before we use it.
--HG--
extra : rebase_source : f757b8320788220b5a4d5242a0264d577d92f15e
Having the Impl suffix isn't really necessary, and if we start creating
instances of these classes directly, it's also rather ugly. Let's get
rid of them.
As well as adding MOZ_MUST_USE to a number of functions, this patch:
- Changes the return type of nsObserverList::GetObserverList() from |nsresult|
to |void|, because it always returned NS_OK and none of the callers checked
the result.
- Removes an unnecessary |new| check in nsSupportsArray::Enumerate().
--HG--
extra : rebase_source : 3a93124ef2a7db3929119194ceacbc56bc80d2c6
A few callers of NS_NewISupportsArray() didn't use the return value to detect
failure, but instead checked if the |array| argument was null after the call.
This is inconsistent with the majority of the calls to NS_NewISupportsArray().
This patch changes them to be checked in the normal way.
--HG--
extra : rebase_source : bf91836d7c3b159833c303a3716f4d9366f8b76a
It's always NS_OK. The patch also removes an unnecessary failure check as a
result.
--HG--
extra : rebase_source : 3a0c30f9ca0e838682204ed1a8d46d6ab35e20b8
This makes things clearer and removes some unnecessary nsresult checks.
The patch also:
- removes some unnecessary |new| and moz_xmalloc() checks;
- adds MOZ_MUST_USE to some fallible nsVariant methods.
--HG--
extra : rebase_source : fd0bd0c55c22ebf194246ec9997fe971cf282e69
It looks like VC++ doesn't like comparisons of nsCOMPtr to 0 after this
change, but those are bad style anyway, so I removed them from
TestCOMPtr.cpp instead of trying to make them work.
It's an annotation that is used a lot, and should be used even more, so a
shorter name is better.
MozReview-Commit-ID: 1VS4Dney4WX
--HG--
extra : rebase_source : b26919c1b0fcb32e5339adeef5be5becae6032cf
Previously, Omnijar::GetReader(nsIFile*) returned nullptr when using
nested jars. This patch makes it return the outer jar reader in that
case, so we don't end up opening the outer jar file again.
We set a null target only from Web Animations API, so make sure
KeyframeEffectReadOnly::ConstructKeyframeEffect() can handle null target
properly.
MozReview-Commit-ID: D6PoV7PGFj3
--HG--
extra : rebase_source : 4ba2d616d6b2cdfe7985ced29e4454e818d076b8
We are currently generating typelib data for all interfaces. Apparently
typelib data is only needed for scriptable interfaces. So let's stop
generating typelib data for interfaces that aren't scriptable.
The impact of this is that some typelibs are dropped from
interfaces.xpt, resulting in ~10kb smaller interfaces.xpt:
* nsIDOMCSSValue
* nsIDOMDOMImplementation
* nsIDOMDOMCursor
* nsIProfilerStartParams
* nsIStreamingProtocolMetaData
* nsIDOMCharacterData
* nsIPrintSession
* nsIDOMDocumentFragment
* nsIDOMProcessingInstruction
* nsIDOMElement
* nsIDOMText
* nsIDOMXULElement
* nsIDOMAttr
* nsIDOMGeoPositionError
* nsIXMLHttpRequestEventTarget
* nsIDOMCSSStyleDeclaration
* nsIDOMCSSStyleSheet
* nsIDOMDocument
* nsIDOMClientRect
* nsIDOMMozNamedAttrMap
* nsIDOMNode
* nsIThreadObserver
* nsIDOMDocumentType
* nsIXMLHttpRequestUpload
* nsISelection
* nsIDOMCDATASection
* nsIDOMDOMRequest
* nsIDOMComment
* nsIDOMEvent
MozReview-Commit-ID: 3LYdNYs7Tum
--HG--
extra : rebase_source : 4ed0e6ef761b165108b8581077f2bf7eddd02274
When PluginInstanceChild receives native key events, it should post the events to the chrome process first for checking if the key combination is reserved. However, posting all key events to the chrome process may make damage to the performance of text input. Therefore, this patch starts to post a key event whose key combination may be a shortcut key. However, for avoiding to shuffle the event order, it posts following key events until all posted key events are handled by the chrome process.
For receiving response from widget, this patch defines nsIKeyEventInPluginCallback. It's specified by nsIWidget::OnWindowedPluginKeyEvent() for ensuring the caller will receive the reply. Basically, the caller of nsIWidget::OnWindowedPluginKeyEvent() should reply to the child process. However, if the widget is a PuppetWidget, it cannot return the result synchronously. Therefore, PuppetWidget::OnWindowedPluginKeyEvent() returns NS_SUCCESS_EVENT_HANDLED_ASYNCHRONOUSLY and stores the callback to mKeyEventInPluginCallbacks. Then, TabParent::HandledWindowedPluginKeyEvent() will call PuppetWidget::HandledWindowedPluginKeyEvent().
MozReview-Commit-ID: G6brOU26NwQ
--HG--
extra : rebase_source : 8140456de278956d2d594e85c7b397ae366b4962
Outer pointers for object aggregation never get used. Having these
always-null pointers around means extra space to store them and extra
instructions to deal with them. Let's just remove them.
js::Class op are often all null. And when they're not all null, they're often
duplicated among classes. By pulling them out into their own struct, and using a
(possibly null) pointer in js::Class, we can save 114 KiB per process on
64-bit, and half that on 32-bit.
* * *
imported patch separate-ClassOps-2
--HG--
extra : rebase_source : bd751bf247e9491c1966a123dbeffa573657dfb1
XPCOMThreadWrapper::GetCurrent() is failing because it's not keeping
AbstractThread::sCurrentThreadTLS up to date. This causes assertion failures
during startup of the GMP stack when dispatching via InvokeAsync to the GMP
thread, which is an XPCOM thread wrapped by the XPCOMThreadWrapper.
We can trivially initialize AbstractThread::sCurrentThreadTLS to be the
XPCOMThreadWrapper on the target thread, since it's thread-local-storage, and
the target thread won't change.
MozReview-Commit-ID: EIEFZppR2PS
This will help identify the cause of some Firefox start-up crashes when JS
initialization fails.
--HG--
extra : rebase_source : 3ed3c5e60f487e0ca11dc13bab93aa820ca8273f
This required reordering a bunch of stuff, so I took the opportunity to do a
big reordering. The new order:
- class CheckStaticAtomSizes;
- class DynamicAtom, class StaticAtom, their methods;
- gAtomTable and related functions;
- ~DynamicAtom() (here because it depends on gAtomTable stuff);
- gStaticAtomTable and related functions;
- exported functions.
--HG--
extra : rebase_source : 5fd4bf9a3f0c628dc3f74c0d8a81aadf48fd6dd7
This avoids the need for some virtual function calls and also will help lead to
distinct representations for dynamic and static atoms.
--HG--
extra : rebase_source : 16bbe6f1e1309ee3e4fab7a0d222e638178a2a9c
This patch changes things so that dynamic atoms and static atoms have distinct
implementations. This is a step towards allowing dynamic atoms and static atoms
to have different layouts in memory, which will allow static atoms to be
represented more compactly.
Specifically, the patch does the following.
- It renames AtomImpl as DynamicAtom and PermanentAtomImpl as StaticAtom, and
the latter is no longer a subclass of the former. This required duplicating
some methods from the former into the latter: ScriptableToString(),
ToUTF8String(), ScriptableEquals(), IsStaticAtom(). (This duplication will
disappear in the future if the representations of dynamic atoms and static
atoms diverge. Indeed, SizeOfIncludingThis() is already different in the two
classes.)
- It replaces all mentions of "permanent"/"non-permanent" atoms with
"static"/"dynamic".
- In ~DynamicAtom() it removes the check that causes gAtomTable to be deleted
when it becomes empty. This will only happen at shutdown and so doesn't seem
useful.
- It documents better various things, especially the basics of the
dynamic/static split, the transmutation of dynamic atoms to static atoms, and
the details of the SizeOf functions.
--HG--
extra : rebase_source : dbf903012e70ebf1a43de1e1088db1bc1b8dd4f4
Also fixes bug 926980 - load ICU data from an archive file.
Stop invoking ICU's autoconf build system. Instead, have hand-authored
moz.build files under config/external/icu to build what we need. In addition,
we'll commit a pre-built copy of the ICU data file (currently icudt56l.dat)
under config/external/icu/data to avoid having to build ICU host tools to
generate it. config/external/icu/data also contains some assembly files
which can generate an object file containing the ICU data file contents
so that the JS shell (or standalone JS builds) can be linked directly to
the data without having to deal with the external data file. This requires
yasm or GNU as.
Various bits of packaging have been updated to account for the ICU data file.
XPCOM initialization now sets the ICU data directory so ICU can locate its
data file.
The update-icu.sh script has been modified to read the list of C/C++ source
files out of the ICU Makefiles and update `sources.mozbuild` files under
config/external/icu, as well as build a local copy of ICU using its
autoconf build system to generate the ICU data file to be committed in-tree.
MozReview-Commit-ID: 8Pfkzqt6S1W
--HG--
extra : rebase_source : 31426cddddb5543e0191059ba2f2eb069abe7727
This patch makes NativeProperties variable-length and reduces static data by
110,336 bytes on 64-bit, and half that on 32-bit.
MozReview-Commit-ID: 2etZ5AnEhgO
--HG--
extra : rebase_source : 6a167b64df7da3c6940114782fe08337f04a694d
The former is only used inconsequentially in tests. The second is not used at
all.
--HG--
extra : rebase_source : 4cfe11f933f1fe8f788e823c5107941085cef92c
The behavior of ::BrowserTabsRemoteAutostart() shouldn't change, meaning that every result remains the same. The new getter can be accessed by JS through Services.appinfo.multiprocessBlockPolicy
MozReview-Commit-ID: 62PpbeJcMCI
There are about 600 of these, at 16 bytes each, and this change makes all of
them shareable between processes
--HG--
extra : rebase_source : b1824f0a022389aeb02d925c4d788e5a671bf782
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. So hopefully
this patch never lands because someone insists of fixing the underlying
problem instead. But if it does land, hopefully the workaround is
only temporary.
MozReview-Commit-ID: 9AkkAUDMln6
--HG--
extra : rebase_source : 76126361de678729344b0e9eaeac1d523f88ebb4
We only ever execute this in one place, so we can just have the main
action do the --regen --cachedir=. mode of operation.
MozReview-Commit-ID: Fis4YBPFjMl
--HG--
extra : rebase_source : f19ac1ad688115c0aee4bf307b72d6207512f702
We can just generate xpidllex.py/xpidlyacc.py in the current directory
rather than one directory higher, and specify this directory as an
include path to xpidl-process.py
MozReview-Commit-ID: KLoGjudc4Y8
--HG--
extra : rebase_source : 8dda268c6490cdfb8b896de9da5b789208584193
We have some oddities in our jemalloc stats reporting.
- "heap-overhead-ratio" is a strange measurement: overhead / non-overhead,
expressed as a percentage. And it omits "bin_unused", which appears to be an
oversight.
- "heap-committed" also omits "bin_unused".
- There are some minor errors in memory report descriptions.
This patch fixes these and improves the heap reporting. It makes the following
reporting changes:
- "heap-allocated": Duplicated as "heap-committed/allocated". (We keep
"heap-allocated" because that's a special value used in the computation of
"heap-unclassified".)
- "heap-committed/overhead": Added; it's the same as the sum of the
"explicit/heap-overhead/*" values. Together with "heap-committed/allocated"
it shows clearly what fraction of the heap is overhead and what fraction is
useful.
- "heap-committed": Removed; now implicit as the "heap-committed/" node.
- "heap-overhead-ratio":
- Removed from memory reports; now shown as the percentage of the new
"heap-committed/overhead" node.
- Still available as a distinguished amount (because it's useful in
isolation) but renamed to heapOverheadFraction, and the telemetry ID is
renamed as MEMORY_HEAP_OVERHEAD_FRACTION.
- "heap-chunks": Removed; it's not that interesting, and can be manually
computed as "heap-mapped" / "heap-chunksize" if necessary.
--HG--
extra : rebase_source : 6f238cda780eb17b2de2f8b9a0b04377c93b109c
service. This is needed so that chrome processes know where sandboxed content
processes will be writing their temp files, and so that content processes know
where to write; r?bsmedberg
MozReview-Commit-ID: BK9bTxFGvZO
--HG--
extra : rebase_source : dec290c82fb934ceadc0c9ce0cf87337aa1e8f47
Part 1: Refactored LoadLibrarySystem32 to expose the system32-path
construction code, so it can be re-used in the following patch.
MozReview-Commit-ID: J5BcI34VPnN
GetSerialNumber accesses global state through gSerialNumbers. We call
GetSerialNumber under a lock when doing normal object refcount logging.
However, we call GetSerialNumber outside of a lock when we're tracing
individual classes for nsCOMPtr refcount logging, even if we don't
actually care about nsCOMPtr refcount logging. We should call it under
a lock always.
UniquePtr is more standard than ScopedFreePtr; using standard constructs
whenever possible is preferable. In this particular case, since we
really just need a chunk of memory, we can allocate a char[] via
MakeUnique.
XPTInterfaceDescriptor::num_additional_types can easily fit in 8 bits -- in
practice it doesn't exceed 20, and there's already a check in DoTypeDescriptor
that it doesn't exceed 255. This patch shrinks it and moves that check into
XPT_InterfaceDescriptorAddTypes() so that any overflow would be detected more
reliably.
On 64-bit platforms this reduces sizeof(XPTInterfaceDescriptor) from 40 to 32
and correspondingly reduces "xpti-working-set" by 16 KiB.
The patch also changes XPT_InterfaceDescriptorAddTypes() into a local function,
because it's defined and only used in xpt_struct.cpp.
--HG--
extra : rebase_source : 754a343bd52c3db35b21a4055a94c7235a70a7a2
This patch:
- Removes XPTArena's ability to support arbitrary alignments.
- Hardwires two sub-arenas into XPTArena, one with alignment of 8 and one with
alignment of 1.
- Uses the first sub-arena for most allocations and the second sub-arena for C
string allocations.
These changes reduce "xpti-working-set" by 56 KiB.
The patch also renames all the used of "malloc" in XPT identifiers with
"calloc", to make clearer that the result is always zeroed.
--HG--
extra : rebase_source : 8e6cc42644621a7f3c80593006734e25420c7229
With careful layout we can reduce sizeof(XPTTypeDescriptor) from 4 to 3, which
also reduces sizeof(XPTParamDescriptor) from 6 to 4. This reduces
"xpti-working-set" by 16 KiB.
The union-of-structs also improves readability by making it clearer exactly
which fields are used for which types.
--HG--
extra : rebase_source : 08060096f93c756fda847b90b45df1b1b207e2b5
This requires merging XPT_DoHeaderPrologue() and XPT_DoHeader(), which is
straightforward.
This reduces "xpti-working-set" by 16 KiB on 64-bit platforms.
--HG--
extra : rebase_source : 74510d6aefe8adc20064bee2c729d7a55fe4b58a
Removing it reduces the "xpti-working-set" measurement by 16 KiB (measured on
64-bit).
--HG--
extra : rebase_source : e6d3911f96ee498a8990b702bb8fa499e55ececb
XPTTypeDescriptor::argnum2 is unused. Removing it reduces
sizeof(XPTTypeDescriptor) from 6 bytes to 4 bytes, which reduces the
"xpti-working-set" measurement by 80 KiB (measured on 64-bit).
--HG--
extra : rebase_source : e89f83df810d0466b724d8307fb567e2a93a3809
Even though the .xpt files we produce never have annotations, .xpt files in the
wild might have them. This partly undoes part 3 of bug 1248534.
--HG--
extra : rebase_source : c0ff4e5ea7afc66f83b1314ee1d7fe0594f9b644
XPT has some functions and macros for freeing memory. However, they (a) are
only used on error paths, and (b) don't actually free memory -- they just
optionally log the "freeing" -- because piecewise freeing doesn't make sense
with arena allocation.
This patch removes all that unnecessary machinery.
--HG--
extra : rebase_source : 40fb8dfd3851a89aaf0501ae290b3a6ca8ac90bc
RegisterBuffer() is the only place that creates an XPTState, and it also
destroys it. So the XPTState can be allocated on the stack, which voids the
need for the creation of an XPTArena.
--HG--
extra : rebase_source : b25f0e798d72b8742efc96793a927f8a060101cf
XPT supports annotations but xpt.py doesn't generate them except for a single
empty annotation (to indicate there are no real annotations). So we can remove
almost all support for them. This also allows XPTString to be removed.
--HG--
extra : rebase_source : 889e635e9167f31c38c015bafe943f2c577f1daf
Currently XPT can both encode and decode, but encoding has been handled by
Python code since bug 643817, so the encoding support can be removed. This
results in many simplifications. Some notable changes:
- All the XPTHashTable code (including XPTDatapool::offset_map) is no longer
necessary.
- PrimitiveTest.cpp and SimpleTypeLib.cpp both don't make much sense without
encoding support, so I removed them.
- A lot of the version code was already unused, e.g. XPT_VERSION_*,
XPT_TYPELIB_VERSIONS_STRUCT, XPT_TYPELIB_VERSIONS.
XPT_MAJOR_INCOMPATIBLE_VERSION is the only thing actually used in version
checks.
- The patch also removes some code that was dead even before encoding removal,
such as XPT_ParseVersionString().
--HG--
extra : rebase_source : 11cfe0b01efde4e2ff0c74b02b408baebedd3dd8
The WindowsAddressSpaceReporter generates one memory report per segment, and
there can be 10,000+ segments.
This patch changes things so that one memory report is generated per segment
*kind* -- at most a couple of dozen -- rather than one per *segment*.
--HG--
extra : rebase_source : bbe86562ee486fd5fbb5d48ff2cc59a6f4c7b4c9
Using explicit iteration at measurement sites is much simpler and nicer than
using callbacks.
--HG--
extra : rebase_source : 8b3f7aa702743b665383766b66a866a2c3d17240
This patch brings the behavior of this method into line with the comment that
describes it and other methods in this class that have a similar test.
I discovered this bug while exercising this code from animation code and was
getting test failures due to returning -Infinity instead of the expected
Infinity.
This patch removes NameTableEntry::mString. This requires adding mNameArray to
NameTableKey so that we can index off it in matchNameKeysCaseInsensitive().
This change saves 41.5 KiB per process.
Be warned. Do not attemp to change the .js "test" source code in ./js
They are meant to check
- the outdated 0666 octal constant is still parsed correctly,
- the outdated 0666 octal constant raises syntax error flag
in strict mode, etc.
So leave them alone.
This will run the SpiderMonkey promise jobs more or less the same way that we
run Promise jobs right now, including using a Web IDL callback for the actual
invocation.
This commit contains a few things:
* Update our copy of google-breakpad to upstream c53ed143108948eb7e2d7ee77dc8c0d92050ce7c
* Get rid of all but one local patch, fold a few related local patches into one
* Misc build fixup to sync with upstream--adding a few new moz.build files,
source files
* The final bits of unhooking Breakpad from the profiler:
** Revert to only building toolkit/crashreporter if MOZ_CRASHREPORTER.
** Stop building bits of Breakpad that we only needed for the profiler.
** Remove a few bits of profiler code that were used to interface with Breakpad.
** Remove toolkit/crashreporter/breakpad-logging, which was only used to
suppress Breakpad logging for the in-process stackwalker.
* Upstream removed their Android-compat sys/ucontext.h because the Android NDK
added it, but the bionic we're using for Gonk builds is too old, so add a
copy of the previous version of those files to
toolkit/crashreporter/gonk-include to keep Gonk building.
* Consolidate moz.build files under toolkit/crashreporter/google-breakpad/client/linux
--HG--
rename : toolkit/crashreporter/google-breakpad/src/common/pathname_stripper.h => toolkit/crashreporter/google-breakpad/src/processor/pathname_stripper.h
rename : toolkit/crashreporter/google-breakpad/src/common/pathname_stripper_unittest.cc => toolkit/crashreporter/google-breakpad/src/processor/pathname_stripper_unittest.cc
extra : histedit_source : 43e65f5432657f548cac5aa7936461e58454c3b6%2C7b56ccc79d9d58ebde0583d920f3593e25212621
extra : rebase_source : f6dbfb8fb2ba5b27e63b26d57c404962679c7a76
extra : commitid : DMQlXPms868
extra : source : 09fd4f3ab6e764016fe073efb226f03b5969af59
extra : intermediate-source : 16f9d3a6d2ef6a6efd088e3b8eff0a4723daef8f
StringBeginsWith (resp. StringEndsWith) takes a defaulted
nsStringComparator object for doing comparisons. The flexibility this
affords is great, but the cost is not: nsStringComparator has virtual
methods, so initializing that defaulted object (at every callsite)
requires a temporary object whose vtable must be initialized.
Since the overwhemingly common case is to use the default comparator
anyway, we should not use defaulted arguments and instead provide the
default comparator/user-provided comparator cases as separate overloads.
This change eliminates the virtual call for the majority of callsites
and reduces codesize as well.