This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
Clang format does not always reflow comments correctly to get them
within 80 columns.
The major categories of failures I have noticed in xpcom/ are:
- Comments that are lists. I fixed these by manually getting them so
they'll be within 80 columns after clang-format runs.
- Comments intermixed with lists of things like enums, initializers,
or even fields in a class. It doesn't seem to associate the comment
with the item in the list correctly. The worst cases of these happen
when it changes initializer lists from having commas at the start of
each item to having them at the end. In the initializer comma cases,
I fixed them by making the commas at the end, so clang-format won't
mix things up. For other cases, I often moved the comment for an
item onto its own line, because it was not possible to have both the
comment and the item on the same line and stay within 80 columns.
- One odd case is nsEnumeratorUtils.cpp, where the end of line comment
after a NS_DECL macro confused clang-format and made it stop
realizing that the NS_DECL thing was a complete statement. I also
added a blank line to that file before a declaration because I think
that is better.
Depends on D13183
Differential Revision: https://phabricator.services.mozilla.com/D13184
--HG--
extra : moz-landing-system : lando
Clang format makes this code look pretty bad, but I think it is safe
to just remove it.
Depends on D13182
Differential Revision: https://phabricator.services.mozilla.com/D13183
--HG--
extra : moz-landing-system : lando
We're paying two function calls from Gecko_AddRefAtom /
Gecko_ReleaseAtom for no good reason, plus it's simple enough it's probably
worth to inline it anyway for C++ callers.
Differential Revision: https://phabricator.services.mozilla.com/D12860
--HG--
extra : moz-landing-system : lando
The core loop of Iterator::Next() requires multiple branches, one to
check for entry liveness and one to check for wraparound. We can
rewrite this to use masking instead, as well as iterating only over the
hashes, and reconstructing the entry pointer when we know we've reached
a live entry. This change cuts the time taken on the collections
benchmark by the iteration portion in half.
As discussed in the previous commit message, PLDHashTable's storage
wastes space for common entry types. This commit reorganizes the
storage to store all the hashes packed together, followed by all the
entries, which eliminates said waste.
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
The only place where this is used where the const-ness matters is in
AddressEntry, and that use const_cast's away the const-ness. So let's
just ditch the method that attempts to return const pointers.
This change is satisfying insofar as it removes a load from every
iteration step over the hashtable, but it doesn't seem to affect
our collection benchmarks in any way. The change does not make
iterators any larger, as there is padding at the end of the iterator
structure on both 32- and 64-bit platforms.
This refactors the observer service code to improve readability, uses MOZ_TRY
and other checking macros wherever possible to simplify error handling and
replaces the ObserverRef class with the more generic nsMaybeWeakPtr class.
This cuts away some code and halves the amount of memory needed to store an
event listener. The external behavior is almost unchanged save for some error
codes which are now more specific.
Differential Revision: https://phabricator.services.mozilla.com/D11646
--HG--
extra : source : 10d910aa9f31435116a718bafe8a2b71c61fe23d
We only use its value in one place, and said value is easily computable
from readily available information. This change makes iterators
slightly smaller.
This adds a new class for the marquee tag, instead of overloading HTMLDivElement.
It removes some of the XBL that was used to expose properties to web content.
Differential Revision: https://phabricator.services.mozilla.com/D3824
--HG--
extra : moz-landing-system : lando
And thus massively speed up ascii-case-insensitive atom comparisons when both
atoms are lowercase (which is the common case by far).
This removes almost all the slow selector-matching in this page, and it seems
an easier fix than storing the lowercased version of all class-names in quirks
mode in elements and selectors...
Differential Revision: https://phabricator.services.mozilla.com/D10945
--HG--
extra : moz-landing-system : lando
This is a rebase + manual refcounting on some places, + cleanup of the original
patch in the bug.
Co-authored-by: Nicholas Nethercote <nnethercote@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D11035
Other frames calling InitAndWrapInColumnSetFrameIfNeeded() needs to be
modified to support column-span (bug 1489295).
Depends on D5208
Differential Revision: https://phabricator.services.mozilla.com/D5209
--HG--
extra : moz-landing-system : lando
Move XUL persistence handling into it's own class and make it a separate
nsIDocumentObserver so it can also be used in non-XUL documents.
To avoid adding persistence to all non-XUL documents, a document must add
the "mozpersist" attribute to the root element if it wants enable the
feature.
Differential Revision: https://phabricator.services.mozilla.com/D6802
--HG--
extra : moz-landing-system : lando
This is needed for bug 1500926. It takes the approach of taking a JSFlatString
and using AutoAssertCannotGC to read the memory directly from the JS heap.
This lets us avoid re-encoding strings when performing lookups, which can be
advantageous.
Only ASCII strings are supported by this handler, and wide strings are hashed
as though they contain only values under 0x7f. This is OK as invalid keys to
perfecthash may return any hashtable entry.
Differential Revision: https://phabricator.services.mozilla.com/D9405
This commit adds a scroll origin, nsGkAtoms::relative, which can be used to
mark main thread scrolling that can be combined with a concurrent APZ scroll.
The behavior of this is controlled by a pref, apz.relative-update. This pref
is initially activated and is intended as an aid to narrowing down causes
of regressions for users in bug reports.
Relative scroll updates work by tracking the last sent or accepted APZ
scroll offset. This is sent along with every FrameMetrics. Additionally,
a flag is added to FrameMetrics, mIsRelative, indicating whether the
scroll offset can be combined with a potential APZ scroll. When this
flag is set, AsyncPanZoomController will apply the delta between the sent
base scroll offset, and sent new scroll offset.
This flag is controlled by the last scroll origin on nsGfxScrollFrame. The
new origin, `relative`, is marked as being able to clobber APZ updates,
but can only be set if all scrolls since the last repaint request or
layers transaction have been relative.
Differential Revision: https://phabricator.services.mozilla.com/D8234
--HG--
extra : rebase_source : 51351a84c9cda228a0975e22eda3fd3bd8d261c4
extra : histedit_source : 4b564c19b16fe2bd26adc671b62b7cb6106e8163
Specifically:
- nsICSSAnonBoxPseudo --> nsCSSAnonBoxPseudoStaticAtom
- nsICSSPseudoElement --> nsCSSPseudoElementStaticAtom
The `nsI` prefix isn't necessary because these are no longer XPIDL types, and
the `StaticAtom` suffix makes their meaning clearer.
--HG--
extra : rebase_source : b68dd7c73f5036dcd6be4c3700b757441f59f9f2
This saves one word per static atom, per process.
The `nsGkAtoms` change is only a small part of this commit.
In regen_atoms.py:
- There is now only one link name per platform: nsGkAtoms::sAtoms[].
- But there is a new constant per atom, giving the index into
nsGkAtoms::sAtoms[].
- And the `atom!` macro for each atom indexes into nsGkAtoms::sAtoms[] using
the index constant.
- A couple of `*mut` pointers are now `*const`.
Elsewhere, the `(nsStaticAtom*)` casts within the `AppendElement()` calls are
necessary to avoid link errors, presumably due to some template instantiation
wrinkle.
--HG--
extra : rebase_source : 629642e708c8bc6e27d6057beae5f35955fdd837
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
Presumably the commit that introduced `aStringOffset` could have removed this,
but overlooked it.
--HG--
extra : rebase_source : 176f14ce01c18ed4c83892d2b7a9e7a54fb5c836
Static atom registration is a bit of a mess. NS_InitAtomTable() calls
nsGkAtoms::RegisterStaticAtoms(), which calls NS_RegisterStaticAtoms(); i.e. we
go from nsAtomTable.cpp to nsGkAtoms.cpp and back.
(And NS_RegisterStaticAtoms() is declared in a .cpp file, not a .h file!)
This commit makes NS_InitAtomTable() a friend of nsGkAtoms, so NS_InitAtomTable
can see nsGkAtoms's atoms array directly, thus removing the need for
NS_RegisterAtomTable() and nsGkAtoms::RegisterStaticAtoms().
This commit also removes an out-of-date part of a comment from XPCOMInit.cpp.
--HG--
extra : rebase_source : 7e1f9aa0a9f7cb5088159fe4c953948b931f6d68
nsGkAtoms.h has a big comment explaining how static atom definitions get
expanded by macros. This comment was very useful when there were multiple
sources of static atoms and their definitions used macros a lot. But bug
1482782 combined all the static atom sources into nsGkAtoms and removed a lot
of macro use. So now the comment is now something of a hindrance, duplicating
quite a bit of the code (and not entirely accurately).
This commit removes the big comment, and moves the still-useful parts inline
with the code. This makes things much easier to follow.
This commit also reformats some of the remaining macros so they are easier to
read.
--HG--
extra : rebase_source : 4377be2fa0edc4ea1f592985ded89acbb76fb104
