The 'x' prefix makes it clearer that these are infallible.
A couple of nsJSID methods are now also infallible.
--HG--
extra : rebase_source : fcce44a00212d6d341afbf3827b31bd4f7355ad5
There are surprisingly many of them.
(Plus a couple of unnecessary checks after `new` calls that were nearby.)
--HG--
extra : rebase_source : 47b6d5d7c5c99b1b50b396daf7a3b67abfd74fc1
This allows JS callers to automatically get the correct types during
interation, without having to explicitly specify them.
Differential Revision: https://phabricator.services.mozilla.com/D3728
--HG--
extra : rebase_source : b708f382d8ea571d199c669bfed5b5a7ca9ffac4
extra : histedit_source : 7df6feb82088c8a5ca45dc28fe4d2b852c177fee
This patch adds simple stubs to convert between the nsISimpleEnumerator
iteration protocol and the JS iteration protocol.
Each iterable object is required to have an @@iterator method which returns an
object implementing the iterator protocol. The later objects, by convention,
also have such a method which returns the object itself.
This patch adds both a @@iterator() and entries() methods to
nsISimpleEnumerator. The former returns an iterator which returns plain
nsISupports objects. The latter accepts an IID and queries each element to
that IID before returning it. If any element fails to query, the error is
propagated to the caller.
Differential Revision: https://phabricator.services.mozilla.com/D3727
--HG--
extra : rebase_source : 340eb43a1c5e6d7ae69fa8ee486d66d31d079b14
extra : histedit_source : f3efc6c265851a563968ee410e4626e0540f55c0
The nsISimpleEnumerator contract specifies that GetNext() returns
NS_ERROR_FAILURE when iteration is complete. Several implementations, however,
either return NS_OK and a null result, or return some other error code, when
iteration is complete.
Since my initial implementation of the JS iteration stubs rely on the
contract-defined behavior of GetNext(), these need to be fixed before it can
land.
Differential Revision: https://phabricator.services.mozilla.com/D3726
--HG--
extra : rebase_source : aab0395df52e18ccff5b0a2489a983013bf484b1
extra : histedit_source : a5644f0a88799b4463af9dd01dfec33b373b1f58
In order to allow JS callers to use nsISimpleEnumerator instances with the JS
iteration protocol, we'll need to additional methods to every instance. Since
we currently have a large number of unrelated implementations, it would be
best if they could share the same implementation for the JS portion of the
protocol.
This patch adds a stub nsSimpleEnumerator base class, and updates all existing
implementations to inherit from it. A follow-up will add a new base interface
to this class, and implement the additional functionality required for JS
iteration.
Differential Revision: https://phabricator.services.mozilla.com/D3725
--HG--
extra : rebase_source : ad66d7b266856d5a750c772e4710679fab9434b1
extra : histedit_source : a83ebffbf2f0b191ba7de9007f73def6b9a955b8
In order to implement profile-per-install we need a mutable INI parser in early
startup. The current one is implemented in JavaScript and thus not available.
This makes the current read-only C++ INI parser mutable and removes the
JavaScript implementation.
It turns out that the two different implementations of nsIINIParserFactory and
nsIINIParser behaved slightly differently but only in ways that the single test
cared about so I've adjusted things a little to make it work.
The existing C++ implementation did not do validity checks on arguments, this
adds that making empty sections and values illegal.
Differential Revision: https://phabricator.services.mozilla.com/D3851
--HG--
rename : xpcom/tests/unit/test_iniProcessor.js => xpcom/tests/unit/test_iniParser.js
extra : source : 524941c8ed0e048ee51be1bd11082b41428ef490
extra : amend_source : 2de6cef5be97448a41733bedda29d6af34aed27a
Now that :-moz-system-metric is gone, there's no real reason for the atoms to
be separate.
Differential Revision: https://phabricator.services.mozilla.com/D3497
--HG--
extra : moz-landing-system : lando
Correctness improvements:
* UTF errors are handled safely per spec instead of dangerously truncating
strings.
* There are fewer converter implementations.
Performance improvements:
* The old code did exact buffer length math, which meant doing UTF math twice
on each input string (once for length calculation and another time for
conversion). Exact length math is more complicated when handling errors
properly, which the old code didn't do. The new code does UTF math on the
string content only once (when converting) but risks allocating more than
once. There are heuristics in place to lower the probability of
reallocation in cases where the double math avoidance isn't enough of a
saving to absorb an allocation and memcpy.
* Previously, in UTF-16 <-> UTF-8 conversions, an ASCII prefix was optimized
but a single non-ASCII code point pessimized the rest of the string. The
new code tries to get back on the fast ASCII path.
* UTF-16 to Latin1 conversion guarantees less about handling of out-of-range
input to eliminate an operation from the inner loop on x86/x86_64.
* When assigning to a pre-existing string, the new code tries to reuse the
old buffer instead of first releasing the old buffer and then allocating a
new one.
* When reallocating from the new code, the memcpy covers only the data that
is part of the logical length of the old string instead of memcpying the
whole capacity. (For old callers old excess memcpy behavior is preserved
due to bogus callers. See bug 1472113.)
* UTF-8 strings in XPConnect that are in the Latin1 range are passed to
SpiderMonkey as Latin1.
New features:
* Conversion between UTF-8 and Latin1 is added in order to enable faster
future interop between Rust code (or otherwise UTF-8-using code) and text
node and SpiderMonkey code that uses Latin1.
MozReview-Commit-ID: JaJuExfILM9
Summary:
This is a streamlined version of perfecthash.py from xpcom/reflect/xptinfo.
There are a few major changes here:
Instead of providing '(key, value)' pairs to the constructor, callers provide a
list of 'entries'. An optional 'key' parameter allows overriding the function
used to get an entry's key. The default behaviour is as before, destructuring a
(key, value) tuple.
Keys can now be anything which supports the 'memoryview' protocol with 1-byte
elements, rather than being forced to be a 'bytearray'. This allows passing in
types such as bytestrings.
A new 'cxx_codegen' method is now exposed which generates a series of
fully-contained C++ declarations to perform entry lookups. It is possible to
override many parts of this codegen to make it the best fit for your component.
PerfectHash remembers the 'key' function, meaning lookup methods automatically
verify a valid key was passed in, and return 'None' otherwise.
Depends On D2615
Reviewers: froydnj!
Tags: #secure-revision
Bug #: 1479484
Differential Revision: https://phabricator.services.mozilla.com/D2616
Summary:
The plan is to also expose perfecthash.py from this module on the python path.
This also allows us to stop using explicit module loading to load make_dafsa.py.
make_dafsa.py was moved into tools/ to avoid any extra python files from
accidentally ending up on the python path.
Reviewers: froydnj!
Tags: #secure-revision
Bug #: 1479484
Differential Revision: https://phabricator.services.mozilla.com/D2614
--HG--
rename : xpcom/ds/make_dafsa.py => xpcom/ds/tools/make_dafsa.py
Summary:
This is done so we can use Array as the name for the new nsTArray-based
type, rather than having to come up with a new name.
LegacyArray was chosen as the [array] attribute is now effectively deprecated,
and we'd like to remove it ASAP.
Depends On D2334
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2335
Currently we have three ways of representing hash values.
- uint32_t: used in HashFunctions.h.
- PLDHashNumber: defined in PLDHashTable.{h,cpp}.
- js::HashNumber: defined in js/public/Utility.h.
Functions that create hash values with functions from HashFunctions.h use a mix
of these three types. It's a bit of a mess.
This patch introduces mozilla::HashNumber, and redefines PLDHashNumber and
js::HashNumber as synonyms. It also changes HashFunctions.h to use
mozilla::HashNumber throughout instead of uint32_t.
This leaves plenty of places that still use uint32_t that should use
mozilla::HashNumber or one of its synonyms, but I didn't want to tackle that
now.
The patch also:
- Does similar things for the constants defining the number of bits in each
hash number type.
- Moves js::HashNumber from Utility.h to HashTable.h, which is a better spot
for it. (This required changing the signature of ScrambleHashCode(); that's
ok, it'll get moved by the next patch anyway.)
MozReview-Commit-ID: EdoWlCm7OUC
--HG--
extra : rebase_source : 5b92c0c3560eb56850cd8832f8ee514d25e3c16f
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle
that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the place.
Additionally, if moving entries is implemented via memcpy (which is
quite common), PLDHashTable copying around bits *again* is inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead
of copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
Summary:
This is done so we can use Array as the name for the new nsTArray-based
type, rather than having to come up with a new name.
LegacyArray was chosen as the [array] attribute is now effectively deprecated,
and we'd like to remove it ASAP.
Depends On D2334
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2335
When removing an element that exists in the array, there's no need to
perform extra bounds checks for actually removing the element; the
presence of the element guarantees that we have a valid index and a
valid range to remove. So split RemoveElementsAt into a safe interface
and an unsafe interface, and let RemoveElement call the latter as an
internal optimization. The same logic applies to RemoveElementSorted.
We call RemoveElement depressingly often, so this is a nice little win.
Summary:
This is done so we can use Array as the name for the new nsTArray-based
type, rather than having to come up with a new name.
LegacyArray was chosen as the [array] attribute is now effectively deprecated,
and we'd like to remove it ASAP.
Depends On D2334
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2335
This speeds up BenchCollections.PLDHash as follows:
> succ_lookups fail_lookups insert_remove iterate
> 42.8 ms 51.6 ms 21.0 ms 34.9 ms
> 41.8 ms 51.9 ms 20.0 ms 34.6 ms
> 41.6 ms 51.3 ms 19.3 ms 34.5 ms
> 41.6 ms 51.3 ms 19.8 ms 35.0 ms
> 41.7 ms 50.8 ms 20.5 ms 35.2 ms
After:
> succ_lookups fail_lookups insert_remove iterate
> 37.7 ms 33.1 ms 19.7 ms 35.0 ms
> 37.0 ms 32.5 ms 19.1 ms 35.4 ms
> 37.6 ms 33.6 ms 19.2 ms 36.2 ms
> 36.7 ms 33.3 ms 19.1 ms 35.3 ms
> 37.1 ms 33.1 ms 19.1 ms 35.0 ms
Successful lookups are about 1.13x faster, failing lookups are about 1.54x
faster, and insertions/removals are about 1.05x faster.
On Linux64, this increases the size of libxul (as measured by `size`) by a mere
16 bytes.
--HG--
extra : rebase_source : 4bfdee68ba40a0cdd5396964d1647a70fb10736a
Our factory registrations already require that we store nsID pointers, which
we generally handle by using pointers to static data, or arena allocating a
copy of a dynamic ID.
Since we already have viable pointers to these IDs, there's no reason to store
an entire second copy for our hash key. We can use the pointer, instead, which
saves 16 bytes per entry.
MozReview-Commit-ID: 6MgKrXRSHv4
--HG--
extra : source : 5fb0b7746a5d56563b471e3061ccca124ea45485
extra : absorb_source : 275f5d4dc2c02e3d0391ed16e8690dac1e601758
Our factory registrations already require that we store nsID pointers, which
we generally handle by using pointers to static data, or arena allocating a
copy of a dynamic ID.
Since we already have viable pointers to these IDs, there's no reason to store
an entire second copy for our hash key. We can use the pointer, instead, which
saves 16 bytes per entry.
MozReview-Commit-ID: 6MgKrXRSHv4
--HG--
extra : rebase_source : 8d41a3fc5bc1ffe88af998bf9a0ba9ac3331a085
The current code for resizing PLDHashTable modifies the cached hash for
all entries in the old hash table. This is unnecessary, because we're
going to throw away the old hash table shortly, and inefficient, because
writing to memory we're never going to use again just wastes time and
memory bandwidth. Instead, let's avoid the write by pulling out the
cached key and doing the necessary manipulation on local variables,
which is probably slightly faster.
Some callers of PLDHashTable::Search() use const_cast, some others are not
const methods due to non-const PLDHashTable::Search().
This patch removes const_cast from the former and mark some methods of the
latter const.
MozReview-Commit-ID: C8ayoi7mXc1
--HG--
extra : rebase_source : 2cba0339756e3278ba6e5f0e8a11e68217a61d34
PLDHashTable::Search() does not modify any members. So, this method and
methods called by it should be marked as const.
MozReview-Commit-ID: 6g4jrYK1j9E
--HG--
extra : rebase_source : eda6c50c538fec0e8c09cb2ba629735eea6ec711
This also replaces the custom logic in ObserverList with an nsTObserverArray
which has all the necessary logic for stable iteration over a potentially
changing list of items. Unused dependencies were also removed.
--HG--
extra : source : 303478f7f248470a1c747f42dad9cb85c3129f0a
This also replaces the custom logic in ObserverList with an nsTObserverArray
which has all the necessary logic for stable iteration over a potentially
changing list of items. Unused dependencies were also removed.
--HG--
extra : source : 1a83516d2ee5939052c5fb226b81563a0d114ff9
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
This reduces memory usage because we only need one allocation instead of two
for the dynamic atom and its chars, and because we don't need to store a
refcount and a size. It precludes sharing of chars between dynamic atoms, but
we weren't benefiting much from that anyway.
This reduces per-process memory usage by up to several hundred KiB on my
Linux64 box.
One consequence of this change is that we need to allocate + copy in
DOMString::SetKnownLiveAtom(), which could make some things slower.
--HG--
extra : rebase_source : ba4065ea31e509dd985c003614199f73def0596c
Cache AccessibleNode and make it able to operate the same instance by nsINode::GetAccessibleNode
--HG--
extra : rebase_source : 063eec8658af020f5408260d7d581ee76a04bd37
* Create BLOCKQUOTE internal role (also needed for correct exposure of
blockquote element on ATK)
* Add new ARIA roles to internal ARIA map
* Add new roles to existing ARIA roles mochitest and update blockquote
element test to reflect mapping to the new internal role
* Create BLOCKQUOTE internal role (also needed for correct exposure of
blockquote element on ATK)
* Add new ARIA roles to internal ARIA map
* Add new roles to existing ARIA roles mochitest and update blockquote
element test to reflect mapping to the new internal role
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
The DoMouseClick helper is also removed because no other caller can now pass a null aEvent. Other MouseClicked implementations are also updated since aEvent cannot be null, which was already the case.
MozReview-Commit-ID: 3bTJ6cZW9ZA
--HG--
extra : rebase_source : ae1bafe7144f6f428e2ef4e7047d5c64e0a19e8c
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
The schema handling for this is currently a bit ugly, for the sake of
simplifying uplift. In the figure, we should find a way to change the schema
pattern matching based on whether or not the extension is privileged.
MozReview-Commit-ID: CU9WR2Ika6k
--HG--
extra : rebase_source : 28e1c43cf0f0efc01b40757e4e65c4ac5d882258
These were found using some ugly text searches, so it's possible some unused
atoms remain. In the future, we should enforce removing unused atoms using
static analysis. Or just generate the static atoms table based on string atom
names in our code.
This patch leaves unused RDF atoms in place, since those are being dealt with
in another bug.
MozReview-Commit-ID: 1KpH9KsHzQy
--HG--
extra : rebase_source : 8138faa2b16e847da31861abae2bbc1c7bac4e02
Move tracking of persistent window state into nsXULWindow. Also, move
special handling of the width/height of the window into nsXULWindow.
MozReview-Commit-ID: LOmHGyYeNSU
--HG--
extra : rebase_source : bcea16eb6209ff789948644a64968a7325cea4ef
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
For reasons unknown, if you give MSVC:
// Foo.h
struct Foo
{
...
};
extern const Foo gFoo;
// Foo.cpp, which necessarily includes Foo.h.
extern constexpr Foo gFoo = {
};
MSVC will create a static initializer for gFoo and place it in the
read/write data section, rather than the read-only data section.
Removing the `extern const` declaration seems to be enough to make this
problem go away. We need to adjust the declaration of other variables
to compensate for the non-visibility of gFoo in the header file.
Due to the decision to keep the old API on nsXPTInterfaceInfo in part 4, this is
a fairly straightforward patch.
1. I had to change a couple of consumers of `IsRetval()` due to the movement of
that flag.
2. I changed all code which held a nsIInterfaceInfo to hold an `const
nsXPTInterfaceInfo*` instead.
3. I changed code which used the nsIInterfaceInfoManager to instead call the
static methods on nsXPTInterfaceInfo.
This removes properties of XULElement that can easily seen to be unused, even if the attributes they control are still in use. There are other properties that may still be used once or twice, and they are not removed here.
MozReview-Commit-ID: IL6mCvtGQAG
--HG--
extra : rebase_source : 4b22b330d311ef22e3466f517c04d5a19512ab71
Each nsStaticAtomSetup contains a pointer to a static atom, and also a pointer
to the canonical pointer to that static atom. Which is pretty weird! The
notable thing thing about it is that these structs are in an array, and that
gives us the only way to iterate over all static atoms in a single class, for
registration and lookups.
But thanks to various other recent changes to the implementation of static
atoms, we can now put the static atoms themselves into an array, which can be
iterated over. So this patch does that. With that done, nsStaticAtomSetup is no
longer necessary.
According to the `size` utility, on Linux64 this reduces the size of libxul.so
by the following amounts:
> text: 62008 bytes
> data: 20992 bytes
> bss: 21040 bytes
> total: 104040 bytes
- The bss reduction is one word per atom, because the canonical static atom
pointers (e.g. nsGkAtoms::foo) have moved from .bss to .data, because they're
now initialized at compile time instead of runtime.
- The data reduction is one word per atom, because we remove two words per atom
for the nsStaticAtomSetup removal, but gain one word per atom from the
previous bullet point.
- I'm not sure about the text reduction. It's three words per atom. Maybe
because there is one less relocation per atom?
Other notable things in the patch:
- nsICSSAnonBoxPseudo and nsICSSPseudoElement now inherit from nsStaticAtom,
not nsAtom, because that's more precise.
- Each static atoms array now has an enum associated with it, which is used in
various ways.
- In the big comment about the macros at the top of nsStaticAtom.h, the pre-
and post-expansion forms are now shown interleaved. The interleaving reduces
duplication and makes the comment much easier to read and maintain. The
comment also has an introduction that explains the constraints and goals of
the implementation.
- The SUBCLASS macro variations are gone. There are few enough users of these
macros now that always passing the atom type has become simpler.
MozReview-Commit-ID: 1GmfKidLjaU
--HG--
extra : rebase_source : 2352590101fc6693ba388f885ca4714a42963943
This will allow us to work with direct pointers to static atoms that are
initialized at compile-time, rather than pointers to pointers to static atoms
that are initialized at runtime.
MozReview-Commit-ID: K04pEicuqu3
--HG--
extra : rebase_source : c5d895b34567c621f4591769390fc95a4c6ff405
In SourceSurfaceImage::GetTextureClient, we use LookupForAdd. This is
because we typically will create a new TextureClient if there isn't
already one created. This creation can fail because the size is too big,
or we don't have the memory available for it. Unfortunately LookupForAdd
is an infallible operation; it is expected we will always add something
to the hashtable if we don't find an entry. This patch adds an OrRemove
method to cover the corner case where we are unable to complete the
insertion.
The last piece of code that was using these attributes was removed in
https://hg.mozilla.org/mozilla-central/rev/35b7fa5ebd58
MozReview-Commit-ID: FyF7kzlpqMz
--HG--
extra : rebase_source : edaf64a4be92be1f72ff67f90c03eed09173cce3
Currently static atoms are stored on the heap, but their char buffers are
stored in read-only static memory.
This patch changes the representation of nsStaticAtom (thus making it a
non-trivial subclass of nsAtom). Instead of a pointer to the string, it now has
an mStringOffset field which is a 32-bit offset to the string. (This requires
placement of the string and the atom within the same object so that the offset
is known to be small. The docs and macros in nsStaticAtom.h handle that.)
Static and dynamic atoms now store their chars in different ways: nsStaticAtom
stores them inline, nsDynamicAtom has a pointer to separate storage. So
`mString` and GetStringBuffer() move from nsAtom to nsDynamicAtom.
The change to static atoms means they can be made constexpr and stored in
read-only memory instead of on the heap. On 64-bit this reduces the per-process
overhead by 16 bytes; on 32-bit the saving is 12 bytes. (Further reductions
will be possible in follow-up patches.)
The increased use of constexpr required multiple workarounds for MSVC.
- Multiple uses of MOZ_{PUSH,POP}_DISABLE_INTEGRAL_CONSTANT_OVERFLOW_WARNING to
disable warnings about (well-defined!) overflow of unsigned integer
arithmetic.
- The use of -Zc:externConstexpr on all files defining static atoms, to make
MSVC follow the C++ standard(!) and let constexpr variables have external
linkage.
- The use of -constexpr:steps300000 to increase the number of operations
allowed in a constexpr value, in order to handle gGkAtoms, which requires
hashing ~2,500 atom strings.
The patch also changes how HTML5 atoms are handled. They are now treated as
dynamic atoms, i.e. we have "dynamic normal" atoms and "dynamic HTML5 atoms",
and "dynamic atoms" covers both cases, and both are represented via
nsDynamicAtom. The main difference between the two kinds is that dynamic HTML5
atoms still aren't allowed to be used in various operations, most notably
AddRef()/Release(). All this also required moving nsDynamicAtom into the header
file.
There is a slight performance cost to all these changes: now that nsStaticAtom
and nsDynamicAtom store their chars in different ways, a conditional branch is
required in the following functions: Equals(), GetUTF16String(),
WeakAtom::as_slice().
Finally, in about:memory the "explicit/atoms/static/atom-objects" value is no
longer needed, because that memory is static instead of heap-allocated.
MozReview-Commit-ID: 4AxPv05ngZy
These functions no longer perform any refcounting, so the existing names are
misleading.
MozReview-Commit-ID: LX55e0bUP8N
--HG--
extra : rebase_source : 89a3da577325286c1d31723acfd4153754f49703
This function captures a common usage pattern, generalizing the existing
IsMember() function.
MozReview-Commit-ID: 5Pt7kqyGD6Y
--HG--
extra : rebase_source : b03e4cc8f5a4a25da9236420f4b64493664b70e0
It seems silly to have a tiny utils class with a single function in its own
module. This patch moves it into nsStaticAtom.h/nsAtomTable.cpp. It also
renames nsAtomListUtils as nsStaticAtomUtils. Finally, it uses templates to
remove the need for the `aCount` parameter at callsites.
MozReview-Commit-ID: DvJVoZFv89c
--HG--
extra : rebase_source : 1f1dd27d56e46c71c30c10102ac6132a721e23d1
Most of the noise is from the fact that clang-format on parser/html/*.{h,cpp}
reformatted all sorts of stuff. Not running it caused lots of format changes
from the generator... I guess we changed the format rules since the last time
this got run?
MozReview-Commit-ID: IA2G87zUIKN
In SourceSurfaceImage::GetTextureClient, we use LookupForAdd. This is
because we typically will create a new TextureClient if there isn't
already one created. This creation can fail because the size is too big,
or we don't have the memory available for it. Unfortunately LookupForAdd
is an infallible operation; it is expected we will always add something
to the hashtable if we don't find an entry. This patch adds an OrRemove
method to cover the corner case where we are unable to complete the
insertion.
Now that nsGkAtoms is in xpcom/, we can call nsGkAtoms::AddRefAtoms() from
NS_InitAtomTable(), which removes the need for DefaultAtoms, and also removes a
duplicate static atom.
MozReview-Commit-ID: CyfvnvZomzZ
--HG--
extra : rebase_source : 53ead62323a340038c1b4594b1a3eb225aa19626
This list of atoms isn't particularly DOM-ish, and having it in xpcom/ will
help with the next patch.
MozReview-Commit-ID: 1Y3Fhn9lNbh
--HG--
rename : dom/base/nsGkAtomList.h => xpcom/ds/nsGkAtomList.h
rename : dom/base/nsGkAtoms.cpp => xpcom/ds/nsGkAtoms.cpp
rename : dom/base/nsGkAtoms.h => xpcom/ds/nsGkAtoms.h
extra : rebase_source : 0a0f6ab4432e0d58ea4662299b750a8c52325ad5
Without this patch, it's impossible for clients to move a reference into an
nsInterfaceHashtable. That causes at least one extra addref/release pair when
they otherwise could. With this patch, a client can do `hashTable.Put(key,
comptr.forget());` to avoid the additional refcounting.
MozReview-Commit-ID: Ghm7n41ziZp
--HG--
extra : rebase_source : a3e842bf9dfe202134c58e447ecf4fa79851c076
Because (a) that name better indicates that it's a pointer to a pointer, and
(b) because nsStaticAtom::mString is going to be renamed as mAtom in bug
1411469.
MozReview-Commit-ID: D5tuNOstMgr
--HG--
extra : rebase_source : 9344eeea0288c8c52c069ce21e8bc55f6e0f3f6f
By removing the "Atom" suffix, which is redundant.
MozReview-Commit-ID: 4MCX9Icfjrw
--HG--
extra : rebase_source : c3c759a508a8938b59d36dbb20448d2964b98c91
The patch also uses GetStringBuffer() in a couple of appropriate places.
MozReview-Commit-ID: JufCUgmO8JL
--HG--
extra : rebase_source : ecd3f17b5560b19622c86759d605fa122d70e48a
The refcount is only used for dynamic atoms.
On 64-bit, this reduces sizeof(nsStaticAtom) from 24 bytes to 16 bytes, and the
on-heap size from 32 bytes to 16 bytes. This saves 42 KiB per process.
On 32-bit, this reduces sizeof(nsStaticAtom) from 16 bytes to 12 bytes, but the
on-heap size stays at 16 bytes, so memory usage is unchanged.
MozReview-Commit-ID: 7d9H7MRHN9a
--HG--
extra : rebase_source : d3eafb3aaf44a592afd6c89cd0519d043056e65a
Various atom-related things have improved recently.
- The main atom table is now threadsafe (bug 1275755) and so can be accessed on
any thread. It has also been split into pieces (bug 1440824), which greatly
reduces lock contention.
- A cache has been added to the HTML5 parser (bug 1352874) that removes the
need for most of the full table lookups.
As a result, there is no point having a separate static atom table. This patch
removes it.
MozReview-Commit-ID: 8ou1BrnPAwd
--HG--
extra : rebase_source : 0c6ab073b1a20b703705582d28731a68456741e1
The old output had a single value: "atoms-table". The new output looks like
this:
> 649,904 B (00.39%) -- atoms
> ├──350,256 B (00.21%) -- dynamic
> │ ├──235,056 B (00.14%) ── unshared-buffers
> │ └──115,200 B (00.07%) ── atom-objects
> ├──212,992 B (00.13%) ── table
> └───86,656 B (00.05%) ── static/atom-objects
MozReview-Commit-ID: 924vUmxHAlh
--HG--
extra : rebase_source : 6c977546a69eeee62ebc87e335982e8278217484
This converts from the odd `tmp` for `rv` pattern and just returns immediately
on failure instead.
--HG--
extra : rebase_source : 1ad5882c1411e9e10f99201b6233ed87c71a20cc
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
When this was added, the xpcom glue was still a thing, and there was a
distinction between things that would build with mozalloc available and
others. There is no such distinction anymore. Anything that has access
to xpcom has access to infallible allocator functions.
--HG--
extra : rebase_source : 04bce114e940c53709275d0354ea7240df4a051e
Now that nsArray uses nsCOMArray under the hood, we don't have to do weird
ForwardEnumeration hacks to start IndexOf at a non-zero index.
MozReview-Commit-ID: 3ReDV0BT0hn
--HG--
extra : rebase_source : 399a988d00fabaa314eb7592b2aacf277a2ca477
Now that xpcom strings use templates we can combine their `ArenaStrdup`
implementations. `nsTStringRepr` is used so as to allow handling of both
`nsTLiteralString` and `nsTSubstring` types.
--HG--
extra : rebase_source : e77891da589f320507b45f524a3203b3dc9f38e6
extra : histedit_source : 79d3b9a1add191563e0985f0c0e416bd29f24351
This adds support for duplicating both raw `char*` strings and raw `char16_t*`
strings by making the character type generic.
--HG--
extra : rebase_source : bb5245ed71161c8c785684e5a56ac894f03874ea
extra : histedit_source : e94eb738a3982f0cb63a894a0cdfbdf0be2b9cad
It's a sub-class of nsAtom, useful for cases where you know you are dealing
exclusively with static atoms. The nice thing about it is that you can use
raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release
implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.)
MozReview-Commit-ID: 4Q6QHX5h44V
--HG--
extra : rebase_source : e4237f85b4821b684db0ef84d1f9c5e17cdee428
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive. This patch splits that macro into three new ones that are harder to
mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 3e2bbec4737b696e1c86579ae54be4cb3186c100
There are four things that must be provided for every static atom, two of which
have a macro:
- the atom pointer declaration (no macro);
- the atom pointer definition (no macro);
- the atom char buffer (NS_STATIC_ATOM_BUFFER);
- the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP).
This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL
and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros
to make them easier to use (e.g. all the '##' concatenation now happens within
the macros).
One consequence of the change is that all static atoms must be within a class,
so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms).
The patch also adds a big comment explaining how the macros are used, and what
their expansion looks like. This makes it a lot easier to understand how static
atoms work. Correspondingly, the patch removes some small comments scattered
around the macro use points.
MozReview-Commit-ID: wpRyrEOTHE
--HG--
extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
Because it's the type we use to set up static atoms at startup, not the static
atom itself.
The patch accordingly renames some parameters, variables, and NS_STATIC_ATOM,
for consistency.
MozReview-Commit-ID: 1a0KvhYNNw2
--HG--
extra : rebase_source : 5c66e5b2dfe053a368bf3584d957198aec4cce91
These were generated with |./mach eslint --fix xpcom| with the
.eslintignore and xpcom/tests/unit/.eslintrc.js changes from the next
patch.
MozReview-Commit-ID: 8pKkICSK3JQ
--HG--
extra : rebase_source : bbc98050928f27160d8ca63d38aa0c383be95878
This change requires introducing nsID::Clone(). Because it's infallible, the
patch also removes some redundant failure-handling code. (nsMemory::Clone() is
also infallible, so this code was redundant even before this change.)
--HG--
extra : rebase_source : ef22757d3fa814320490bf7e19e822b8f0c4bdc3
The new code is slightly less efficient because it requires measuring the
string length, but these strings are all short so it shouldn't matter.
Note that the case in DataToString() is a little different. The std::min() that
was there appears to be excessive caution -- this code is always printf'ing
some kind of number, so 32 chars should never be reached -- but it was bogus
anyway, because if 32 was exceeded then (a) we would have overflowed `buf`, and
(b) we'd be returning a non-null-terminated string.
--HG--
extra : rebase_source : b666ad72c09d8c32b98bb9abc9dce1bd0c912c9b
They are equivalent -- both infallible, both requiring measuring the length of
the string -- but moz_xstrdup is much more readable. (One place deals with
16-bit strings and so uses NS_strdup instead, which is also infallible.)
The patch also removes some failure-path code that will never execute due to
the infallibility.
--HG--
extra : rebase_source : 115574cf55db90b60e6bee59e5dc6ee409374159
Currently nsAtom::mString points to the interior of an nsStringBuffer. For
static atoms this requires the use of nsFakeStringBuffer, which is pretty
gross.
This patch changes things so that nsAtom::mString points to a static char
buffer for static atoms. This simplifies a number of things:
- nsFakeStringBuffer and CheckStaticAtomSizes are no longer needed.
- FakeBufferRefCountHelper is no longer needed.
- nsAtom's constructor for static atoms is simpler.
- RegisterStaticAtoms() is simpler.
On the flip-side, a couple of things get more complicated.
- nsAtom::ToString() treats static and dynamic atoms differently.
- nsAtom::GetStringBuffer() is now only valid for dynamic atoms. This
function is only used in two places, both involving DOMString, so those
locations are updated appropriately. This also requires updating some other
code assigning nsStrings to DOMStrings, because we can't assume that
nsStrings are shared.
On Linux64 this change reduces the size of the binary by 8752 B, and moves
81968 B from the .data to the .rodata section, where it can be shared between
processes.
--HG--
extra : rebase_source : 0f6fcdec1c525aa66222e208b66a9f9026f69bcb
Bug 1134923 removed the use of those functions in gecko, and left some
for the XPCOM standalone glue. The XPCOM standalone glue was severely
stripped down in bug 1306327, with the effect of removing the
implementation for those functions.
The remains in nsXPCOM.h are:
XPCOM_API(void*) NS_Alloc(size_t aSize);
XPCOM_API(void*) NS_Realloc(void* aPtr, size_t aSize);
XPCOM_API(void) NS_Free(void* aPtr);
With no implementation left, the first arm is never actually used, and
the second arm means every remaining use of those functions in the tree
is a macro expansion to one of moz_xmalloc, moz_xrealloc or free.
--HG--
extra : rebase_source : fd1669abc5a25d8edbd5c3a8522e22a5c3f558e2
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive.
This patch splits that macro into three new ones that are harder to mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 53c8b43b6a1be06d00618a133e28bf95c46a3ba3
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive.
This patch splits that macro into three new ones that are harder to mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 59f77df0124249bfd11fee3585420a17b4201d37
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
This fixes the build in non-unified mode, as nsCOMArray::Sort() method uses
NS_QuickSort().
MozReview-Commit-ID: CDBLIX8D3mL
--HG--
extra : rebase_source : 67902cf10b9311adbd97fecf7906762bb86c52e4
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
nsHtml5Atoms are very similar to dynamic nsAtoms. This patch removes the former
in favour of the latter, which leaves nsAtom as the only subclass of nsIAtom.
nsAtom::mKind is still used to distinguish dynamic atoms from HTML5 atoms, and
the HTML5 parser still uses manual memory management to handle its HTML5 atoms.
nsHtml5AtomEntry::mAtom had to be changed from an nsAutoPtr to a raw pointer
because nsAtom's destructor is private.
MozReview-Commit-ID: 1pBzwkog3ut
--HG--
extra : rebase_source : fbb819e527cb30606348da9ce3eede62e00fb936
This patch moves nsAtom's declaration to nsIAtom.h. In order to keep most of
nsAtom's members private the patch also does the following.
- It introduces a new class, nsAtomFriend, which encapsulates the functions
that will need access to nsAtom's private members.
- It moves GCKind, GCAtomTable(), and GCAtomTableLocked() out of nsAtom.
- It removes the factory methods, and replaces their uses with direct
constructor calls.
MozReview-Commit-ID: L8vfrHsR2cS
--HG--
extra : rebase_source : d38a65515ae82c355966ca80ab235bea11b638af
Because it's going to be exposed via nsIAtom.h in the next few patches.
MozReview-Commit-ID: A81s1nWrvmB
--HG--
extra : rebase_source : 43990feb460fc7343c994f72fb6c6679a3aeb1cc
This patch reduces sizeof(PLDHashTable) as follows.
- 64-bit: from 40 bytes to 32
- 32-bit: from 28 bytes to 20
It does this by doing the following.
- It moves mGeneration from EntryStore to PLDHashTable, to avoid unnecessary
padding on 64-bit. This requires tweaking EntryStore::Set() as explained in a
comment.
- It also shrinks mGeneration from uint32_t to uint16_t, saving 2 bytes of
data.
- It shrinks mEntrySize from uint32_t to uint8_t, to cut 3 bytes of data.
- It shrinks mHashShift from int16_t to uint8_t, trimming another byte of data,
and moves it, saving another 2 bytes of padding.
And it reorders the fields so the word-sized ones are at the start, which makes
it easier to imagine the memory layout.
The patch also adds a test, and fixes some misordered function arguments in
existing tests.
--HG--
extra : rebase_source : 6ed6f7be68477fd4a82f07dd2f51c1f1d9b92dcc
The current code replaces one PLDHashTable's mGeneration with another. If the
two generation values happen to be equal, it will look as though the storage
hasn't changed when really it has.
The fix is to use EntryStore::Set() to update mEntryStore, which increments
mGeneration appropriately.
--HG--
extra : rebase_source : d1779a143746c8d1a3e67bc3685e703496206b0f
Its return value is never used, and most implementations return nullptr anyway.
MozReview-Commit-ID: 8rxC053mmE8
--HG--
extra : rebase_source : 61a0b8b1373396182efd27d3c01b96e5e5541364
Now that nsIAtom is non-scriptable, a .idl file isn't needed.
I made the new nsIAtom.h file by starting with a generated nsIAtom.h file, and
then cleaning it up and removing some stuff that wasn't necessary.
--HG--
extra : rebase_source : 9655fd38984512bd96cf5555048f7774414f6d92
There's no reason for them to be separate, and we can use the |kind| field to
distinguish the two kinds when necessary.
This lets us remove the duplication of ScriptableToString(), ToUTF8String(),
and ScriptableEquals().
It also lets us use |Atom*| pointers instead of |nsIAtom*| pointers in various
places within nsAtomTable.cpp, which de-virtualizes various calls and removes
the need for some static_casts.
--HG--
extra : rebase_source : 2f9183323446e353f8cc5dcedf57d9dc9a38f0a7