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.
This was disabled because it was causing intermittent failures in a
test, but that failure seems to have stopped.
This will cause us to start doing leak checking in content processes
on Windows XP.
FindFreeEntry() has one caller, so using MOZ_ALWAYS_INLINE should be good
enough for it. As for SearchTable(), NS_FASTCALL is the same as
PL_DHASH_FASTCALL and so can be used instead.
--HG--
extra : rebase_source : 814f96d4751922785358e7a4f9d64fcf522364c1
This commit contains a few things:
* 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/client/linux/handler/Makefile.in => toolkit/crashreporter/google-breakpad/src/client/linux/Makefile.in
extra : commitid : HeAH4kH17B1
extra : rebase_source : c9942aaca1d4e9555ecd44a23d7020a8a7ba1d77
extra : source : 31c98f5e107b9271be88e7c8543c4dbb4a2b6526
This commit contains a few things:
* 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/client/linux/handler/Makefile.in => toolkit/crashreporter/google-breakpad/src/client/linux/Makefile.in
extra : commitid : GR2H5y5DM7E
extra : rebase_source : 212b8f04703555658e1df026de2211ea20ac390b
This avoids large amounts of heap churn while watching YouTube videos on Mac
and Linux.
--HG--
extra : rebase_source : 8606947287574826c455c25336c1a42d77ce6dcc
This commit makes CycleCollectedJSRuntime install a nursery collection callback
which traces nursery collections with a new `mozilla::TimelineMarker` subclass.
They're trivial and very hot. This reduces binary size in a 64-bit Linux opt build by 20 KiB and avoiding the calls can only help performance.
--HG--
extra : rebase_source : 774e6ffff9c787fa5444f939d1236d994ac8cf5b
Since we no longer support binary extensions, revving an interface's IID
is not necessary for binary compatibility. However, we currently skip
relinking XPT files if a change to an interface doesn't update its IID.
This patch fixes that requirement by comparing full interfaces against
each other, so that updating an XPIDL interface without rvving its IID
works well with incremental builds.
This paves the way to remove the requirement on revving interface IIDs
when making a change to an XPIDL interface.
Nothing in mozilla-central uses the NS_APP_BOOKMARKS_50_FILE/BMarks key except
tests. It's also not been very useful since the switch to places in ... Firefox
3? so even if addons use it, it's not doing them much good.
BookmarkHTMLUtils.defaultPath returns the same thing anyways for those that
really do insist on getting the equivalent thing (but I'd argue
BookmarkHTMLUtils.defaultPath, as well as the browser.bookmarks.file pref could
just go away as well).
Seamonkey does use NS_APP_BOOKMARKS_50_FILE/BMarks, but they really only need
the #define, which they can add in their source.
Nothing apart the code that was just removed uses those keys, so remove them.
Actually, there is a use in Seamonkey, but considering they're shipping with
omnijar, the code expecting the directory has not been working as designed for
a while, so they can fixup and remove that use as well.
On win32, NS_InvokeByIndex is implemented with inline assembly. This
inline assembly assumes that it is wrapped by the compiler with the
standard x86 prologue and epilogue:
push ebp
mov ebp, esp
[inline assembly that manipulates the stack pointer]
pop ebp
ret
In particular, the last instruction of the inline assembly is:
mov esp, ebp
which cancels out the effects of the stack manipulation performed by all
the inline assembly that proceeds the instruction.
When compiling with clang-cl, however, the above assumption does not
hold, as clang-cl inserts a more complex prologue and epilogue,
something like:
push ebp
mov ebp, esp
sub esp, frame_size
[save registers into stack frame]
[inline assembly that manipulates the stack pointer]
[restore registers from stack frame]
add esp, frame_size
mov esp, ebp
pop ebp
ret
Combining this more extensive prologue and epilogue with the assumptions
of the inline assembly leads to interesting crashes when
NS_InvokeByIndex is called: the inline assembly effectively deallocates
the stack allocated by the inline assembly *and* the stack frame
allocated by the compiler itself. The compiler-generated code then
attemptes to deallocate the stack frame, leading to the crash, as the
code now returns to an unspecified address.
To avoid these sorts of problems in clang-cl and make the code more
robust generally, let's move the NS_InvokeByIndex implementation to a
separate assembly file. We can then write exactly what we need to have
happen, safe from any manipulations of the compiler.
Since we don't compile much (any?) code in Gecko with MASM, we need to
add the /SAFESEH flag to the assembler invocation so that the object
file with be appropriately marked as not containing exception handlers;
the linker (which is invoked with the /SAFESEH flag itself) will then
consent to link it into libxul.
A bunch of threads have their wait time set to PR_INTERVAL_NO_TIMEOUT and so
we divide this by 4 and set waitTime to that. This causes us to wait a very
long but not PR_INTERVAL_NO_TIMEOUT amount of time and so we still update
mIntervalNow and think that we've been hung for a long time when comparing
to the mInterval in the current thread which is set to the previous value of
mIntervalNow.
The JS engine does not export symbols outside of XUL, so having these
defined inside mozglue apparently causes linking errors on some
platforms with the patches in bug 1120016.
This patch moves enough methods outside of mozglue that the patch in
that other bug will still link on all platforms, without moving so
much out that there are other linking errors.
--HG--
rename : xpcom/glue/nsCycleCollectionParticipant.cpp => xpcom/base/nsCycleCollectorTraceJSHelpers.cpp
The patch changes all uses of SizeOfIncludingThisMustBeUnshared() to
SizeOfIncludingThisIfUnshared(). This incurs the (tiny) cost of an unnecessary
IsReadonly() check for guaranteed-unshared strings, but avoids the possible
assertion failures that would occur when MustBeUnshared() was used incorrectly
on shared strings, which is an easy mistake to make.
--HG--
extra : rebase_source : b1e91f1c19bcbe0521b0ce461d6c90512ca938ef
When people write:
array.AppendElement(nsDependentString(...));
(resp. nsDependentCString), it's not clear whether they expect the newly
constructed dependent string to live in the array, or whether they're
just making a nsString-like holder whose contents can be freely copied
into the array's newly-created nsString. Sometimes the latter is what
you prefer, and sometimes the former. In all cases, however, the latter
behavior is what you get.
Let's try to make that behavior more explicit by pre-constructing
nsString elements and then using Assign to show that copying is taking
place. This patch involves no functional change in behavior (it ought
to be epsilon faster due to using AppendElements, rather than repeatedly
calling AppendElement).