This now uses `if constexpr (...)` which is a lot more readable, and still
compiles to almost no assembly instructions, as expected.
Floating point casting assert when casting an integer that's too large to be
represented exactly as a floating point (e.g. UINT64_MAX to double, since double
have less than 64 bytes of mantissa), or when casting a double that's too large
to be represented in a float.
Differential Revision: https://phabricator.services.mozilla.com/D167955
This now uses `if constexpr (...)` which is a lot more readable, and still
compiles to almost no assembly instructions, as expected.
Floating point casting assert when casting an integer that's too large to be
represented exactly as a floating point (e.g. UINT64_MAX to double, since double
have less than 64 bytes of mantissa), or when casting a double that's too large
to be represented in a float.
Differential Revision: https://phabricator.services.mozilla.com/D167955
C++20 deprecated decrement/increment of object of volatile-qualified types, e.g. v++.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1152r3.html
mfbt/SHA1.cpp:400:9 [-Wdeprecated-volatile] compound assignment to object of volatile-qualified type 'volatile unsigned int' is deprecated
mfbt/SHA1.cpp:401:9 [-Wdeprecated-volatile] compound assignment to object of volatile-qualified type 'volatile unsigned int' is deprecated
mfbt/SHA1.cpp:402:9 [-Wdeprecated-volatile] compound assignment to object of volatile-qualified type 'volatile unsigned int' is deprecated
mfbt/SHA1.cpp:403:9 [-Wdeprecated-volatile] compound assignment to object of volatile-qualified type 'volatile unsigned int' is deprecated
mfbt/SHA1.cpp:404:9 [-Wdeprecated-volatile] compound assignment to object of volatile-qualified type 'volatile unsigned int' is deprecated
shaCompress() has a comment emphasizing the importance of the X array being volatile. I verified that changing `XH(0) += A` to `XH(0) = XH(0) + A` generates the same -S assembly code (for clang -O2 on Apple Silicon).
Whether this comment about the volatile code generated by gcc 3.4.3 -O3 in 2012 is still relevant for clang 15 -O2 in 2023 is a different question.
Differential Revision: https://phabricator.services.mozilla.com/D165268
The annotations added in bug 1770158 only covered `StringToDouble`,
however as noted in the comments in that file, that isn't sufficient for
accurately parsing floating point numbers. This patch extends the
annotations to the single-precision floating point numbers as well and
will be used in the next part to clean up the implementation of
`nsTString::ToDouble`.
Differential Revision: https://phabricator.services.mozilla.com/D148304
It's unclear to me when they were disabled, but we do want to enable
these as otherwise there's no way to catch bindgen issues that can end
up in subtle bugs at best, or memory corruption at worst.
Differential Revision: https://phabricator.services.mozilla.com/D162997
It is possible to specify full names for capabilities when using the clang
thread-safety analysis which will be used in error messages. We should use that
form of the attribute rather than the legacy lockable attribute.
Differential Revision: https://phabricator.services.mozilla.com/D160531
Some profiling of tcampbell's React benchmark [1] shows 6.1 million calls to
js::frontend::GeneralTokenStreamChars<..>::getFullAsciiCodePoint, using 110.57
million instructions (x86_64). That comes out to only 18 insns per call,
which suggests the method is a good candidate for inlining, but it isn't
inlined.
Merely parking an inline annotation on it doesn't help much, because it gets
inlined into js::frontend::TokenStreamSpecific<..>::getCodePoint, but that
isn't inlined into *its* caller(s), so the 6.1 million calls move to
::getCodePoint instead.
This patch requests inlining for both ::getFullAsciiCodePoint and
::getCodePoint and adds some MOZ_NEVER_INLINE annotations to ensure that cold
paths *don't* get inlined into these two, to reduce code bloat and avoid
excessive register pressure.
IsAscii functions in mfbt/TextUtils.h have been marked inline as a precaution;
this probably isn't necessary.
Run time with config [2] is reduced from 0.390 seconds to 0.379 seconds
(2.8% speedup, best of 50 runs), and from 0.402 to 0.396 seconds
(median of 50 runs).
Instruction count falls from 3511.8 million to 3395.8 million, and the number
of data accesses from 1563.7 million to 1487.4 million -- a 4.8% reduction
that is probably caused by avoidance of save/restore sequences in the inlined
fns.
[1] https://github.com/mozilla-spidermonkey/matrix-react-bench
[2] Fedora 35, x86_64, Intel Core i5 1135G7 at 4 ish GHz
configure: --disable-debug --enable-optimize="-g -O2"
run: --no-threads
Differential Revision: https://phabricator.services.mozilla.com/D159500
The only uses of this method were removed in Part 1, meaning that it can
now be removed. Support for this method adds a significant amount of
complexity to `BufferList` and IPC serialization.
Differential Revision: https://phabricator.services.mozilla.com/D154439
Deletion of mutation observers from a list resulted in O(n^2) behavior and could lead to massive freezes.
This is resolved by using a LinkedList instead, reducing complexity to O(n).
A safely iterable doubly linked list was implemented based on `mozilla::DoublyLinkedList`,
allowing to insert and remove elements while iterating the list.
Due to the nature of `mozilla::DoublyLinkedList`, every Mutation Observer now inherits `mozilla::DoublyLinkedListElement<T>`.
This implies that a Mutation Observer can only be part of one DoublyLinkedList.
This conflicts with some Mutation Observers, which are being added to multiple `nsINode`s.
To continue supporting this, new MutationObserver base classes `nsMultiMutationObserver` and `nsStubMultiMutationObserver` are introduced,
which create `MutationObserverWrapper` objects each time they are added to a `nsINode`.
The wrapper objects forward every call to the actual observer.
Differential Revision: https://phabricator.services.mozilla.com/D157031
The next patch is creating a cache which is capable of looking up different kind
of string types. However, each string type need some contextual information to
be able to compare them against each others, which adds complexity to the lookup
type. In addition, the keys are of only one string type, and therefore we try to
avoid storing this context as part of each key, but instead provide it with the
contextual information coming with the Lookup type.
Therefore, when we want to insert a key, which might already be present, using
`put`. We have to provide a `aLookup` argument which knows how to compare keys.
This also make the interface similar to `putNew` which already has the
distinctions between the `Lookup` argument and the `KeyInput` argument.
Differential Revision: https://phabricator.services.mozilla.com/D154512
All JSONWriteFuncs are effectively final, this patch enforces that, hopefully
helping the compiler to de-virtualize some calls.
Differential Revision: https://phabricator.services.mozilla.com/D154619
mWriter is now a reference, and the ownership is optional through a separate
member variable that could stay null.
User can now choose to keep the JSONWriteFunc on their stack, which saves a
heap allocation, and makes it easier to access the concrete JSONWriteFunc
implementation directly (instead of through WriteFunc()).
Differential Revision: https://phabricator.services.mozilla.com/D154617
mWriter is never null (and lots of calls just dereference it without checking),
so we may as well enforce it:
- The constructor MOZ_RELEASE_ASSERTs that it's not null.
- The accessor WriteFunc() returns a reference instead of a scary raw pointer.
(Note that we can't make mWriter a NotNull<...>, because the next patch will
give the option to keep that owning pointer null.)
Differential Revision: https://phabricator.services.mozilla.com/D154616
All JSONWriteFuncs are effectively final, this patch enforces that, hopefully
helping the compiler to de-virtualize some calls.
Depends on D154618
Differential Revision: https://phabricator.services.mozilla.com/D154619
mWriter is now a reference, and the ownership is optional through a separate
member variable that could stay null.
User can now choose to keep the JSONWriteFunc on their stack, which saves a
heap allocation, and makes it easier to access the concrete JSONWriteFunc
implementation directly (instead of through WriteFunc()).
Depends on D154616
Differential Revision: https://phabricator.services.mozilla.com/D154617
mWriter is never null (and lots of calls just dereference it without checking),
so we may as well enforce it:
- The constructor MOZ_RELEASE_ASSERTs that it's not null.
- The accessor WriteFunc() returns a reference instead of a scary raw pointer.
(Note that we can't make mWriter a NotNull<...>, because the next patch will
give the option to keep that owning pointer null.)
Differential Revision: https://phabricator.services.mozilla.com/D154616
This patch moves EqualsIgnoreCase to ns[T]StringObsolete, and removes
the aCount argument, instead migrating callers to use `StringBeginsWith`
with a case-insensitive comparator.
In addition, nsTStringRepr::Compare was removed and replaced with either
calls to methods like `StringBeginsWith` or the global `Compare` method.
These changes required some modifications at call-sites but should make
the behaviour less surprising and more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D148299
I split this out into its own commit because it's a bit awkward to go back and
shuffle the old code around. If you'd like me to apply it to the history
though, just let me know.
This patch just moves all of the AVX2 code out from SIMD.cpp into SIMD_avx2.cpp
and removes the -mavx2 flag when compiling SIMD.cpp. On try this removes the
failure on M1 hardware when running the x64 binary.
Differential Revision: https://phabricator.services.mozilla.com/D152920
This only makes sense for AVX2, because widening it from a 64-bit comparison
to a 128-bit comparison is hardly worth it, and there are gaps in the SSE2
instruction set (missing _mm_cmpeq_epi64, which is introduced in SSE4.1) that
would require us to compensate and probably take a sizeable perf hit.
Differential Revision: https://phabricator.services.mozilla.com/D152297
This showed a modest improvement in the geomean of my benchmarking, but
importantly it showed a consistent and relatively strong improvement across
all of the cases which I would guess are more realistic. Notably this change
makes it perform better at iteratively searching for the next occurrence of X
in the HTML of a large web page.
Differential Revision: https://phabricator.services.mozilla.com/D152296
These were the last remaining JSON whitespace characters, so we can now our
regression tests can check that there are non of these left.
Differential Revision: https://phabricator.services.mozilla.com/D152607
This only makes sense for AVX2, because widening it from a 64-bit comparison
to a 128-bit comparison is hardly worth it, and there are gaps in the SSE2
instruction set (missing _mm_cmpeq_epi64, which is introduced in SSE4.1) that
would require us to compensate and probably take a sizeable perf hit.
Differential Revision: https://phabricator.services.mozilla.com/D152297
This showed a modest improvement in the geomean of my benchmarking, but
importantly it showed a consistent and relatively strong improvement across
all of the cases which I would guess are more realistic. Notably this change
makes it perform better at iteratively searching for the next occurrence of X
in the HTML of a large web page.
Differential Revision: https://phabricator.services.mozilla.com/D152296
A custom defintion wrapping fu2::function_base is used to customize the
inline buffer's size and alignment to make it compatible with nsTArray.
Without the custom wrapper, `alignof(max_align_t)` is used, which is
larger than nsTArray's max alignment on some platforms.
Differential Revision: https://phabricator.services.mozilla.com/D145691
A custom defintion wrapping fu2::function_base is used to customize the
inline buffer's size and alignment to make it compatible with nsTArray.
Without the custom wrapper, `alignof(max_align_t)` is used, which is
larger than nsTArray's max alignment on some platforms.
Differential Revision: https://phabricator.services.mozilla.com/D145691
clang-cl doesn't define __GNUC__. Also for some reason, clang-cl doesn't
like the use of MOZ_FORMAT_PRINTF on a function definition (while clang
is apparently happy with it).
Differential Revision: https://phabricator.services.mozilla.com/D144922
Due to how this type of threadsafe refcounting is implemented, it needs to be
implemented using a MFBT-style refcounting base class, somewhat similar to
`SupportsWeakPtr`.
This patch makes NS_IMPL_{ADDREF,RELEASE}_INHERITED intelligently not add
refcount logging for types inheriting from SupportsThreadSafeWeakPtr, as the
default behaviour would break due to weak pointer upgrades not calling through
`AddRef` or `Release`.
In MFBT, the return value of `AddRef` and `Release` on
SupportsThreadSafeWeakPtr is changed to be compatible with nsISupports, so that
this type can be used to implement nsISupports refcounting.
Differential Revision: https://phabricator.services.mozilla.com/D142603
Currently calling Pattern::Clone() produces a heap-allocated Pattern with RefPtrs
to any internal resources such as SourceSurfaces or GradientStops. While this is
okay if the Pattern is transient, this causes problems if the clone is long-lived
and causes via the RefPtr the stored resource to stay alive, even when there are
no other external references to the resource.
In the case of DrawTargetWebgl's PathCache, we need to be able to create Pattern
clones that have internal weak references, while also still supporting the original
use-case of strong references. To this end we template-ize some of the Pattern
derivatives so that we can make either strong or weak versions according to use-case.
This case way we store a weak clone of a Pattern in the PathCache key, the reference
will automatically invalidate itself when all other external strong references to it
go away, without having to do external crawling of the PathCache to constantly prune
the last reference manually.
Differential Revision: https://phabricator.services.mozilla.com/D144381
There are a few places where we call one of two overloads of a fuction based on
the contents of a MaybeOneOf. We can simplify this code by giving the class a
map method.
Differential Revision: https://phabricator.services.mozilla.com/D144595
This patch creates an class managing an input-only audio stream within a
task thread. This class will be used as a source generating the audio
data to a NonNativeInputTrack in the following patch.
Depends on D116535
Differential Revision: https://phabricator.services.mozilla.com/D137911
There weren't that many uses of the existing typedef, so it seemed like
it might be worthwhile to just replace all uses of the previous typedef
with the stl-like one.
Differential Revision: https://phabricator.services.mozilla.com/D142705
This will be used to avoid problematic includes from WorkerPrivate.h,
and it matches the behavior of RefPtr<> and WeakPtr<>.
Differential Revision: https://phabricator.services.mozilla.com/D140658
This will be used to avoid problematic includes from WorkerPrivate.h,
and it matches the behavior of RefPtr<> and WeakPtr<>.
Differential Revision: https://phabricator.services.mozilla.com/D140658
* Accept that finding an explicit unpack for a given stride might fail.
* Directly use the logic from the GLES spec for unpacking stride calculations.
* Use structuredSrcSize member.
* Calc explicit unpack based on dstStride, not srcStride.
Differential Revision: https://phabricator.services.mozilla.com/D136052
These assertions are already diagnostic asserts, and this will make
failures to check Maybe into safe crashes rather than security bugs on
all branches.
A failure to check Maybe is more dangerous than a null pointer
dereference, as the generated code will produce a valid reference to
uninitialized data rather than a null reference which should safely
segfault.
Differential Revision: https://phabricator.services.mozilla.com/D138208
Adding MOZ_CRASH reasons will help disambiguate any of these crashes in crash ping telemetry (which doesn't have symbolicated crash signatures or stack traces like crash reports).
Differential Revision: https://phabricator.services.mozilla.com/D133582
* Fix update.sh to use macOS-compatible mktemp -d flag.
* Rebase use-mozilla-assertions.patch to fix merge conflict.
* Rebase debug-only-functions.patch to fix merge conflict.
* Rebase to-fixed-dbl-max.patch to fix merge conflict.
* Remove to-fixed-digits-after-point.patch because upstream has this fix now.
https://github.com/google/double-conversion/releases/tag/v3.1.6
Cleanups and new architectures:
* Features some code cleanups.
* Adds the following new architectures: loongarch, xtensa, nios2, e2k.
Differential Revision: https://phabricator.services.mozilla.com/D133581
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
This fix simply ignores tablet mode when running on Windows 11. The
reasoning behind this is that per Microsoft documentation tablet mode
is specific to Windows 10 and not supported anymore on Windows 11. This
seems consistent in the behavior of the APIs we use to detect the
presence of a keyboard: Windows 10-specific APIs return unexpected
results while APIs that predate them return values that seem consistent
and reliable.
Differential Revision: https://phabricator.services.mozilla.com/D128229
Generalize RandomUint64() into a new GenerateRandomBytes() function, which will be used in the next changeset to replace nsUUIDGenerator's various platform-specific implementations with one simple implementation.
Differential Revision: https://phabricator.services.mozilla.com/D124311
The next patches remove elements from a segmented vector that is being
iterated. This patch adds assertions to ensure that we don't attempt to use an
iterator that points to a removed element.
The assertions are added to Done() because all the other methods call that.
Differential Revision: https://phabricator.services.mozilla.com/D125426
The next patches remove elements from a segmented vector that is being
iterated. This patch adds assertions to ensure that we don't attempt to use an
iterator that points to a removed element.
The assertions are added to Done() because all the other methods call that.
Differential Revision: https://phabricator.services.mozilla.com/D125426
Without this patch, these MOZ_ASSERT statements cause build errors, if I build
the layout/generic directory in non-unified mode.
(Instead of this patch, we could also hypothetically sprinkle individual
#includes for Assertions.h around to all the downstream files; but it's simpler
and more direct to just put it here in the file that contains the MOZ_ASSERT
statements in question. Note that many other MFBT headers also have includes
for Assertions.h, so it seems reasonable to include it here as well.)
Differential Revision: https://phabricator.services.mozilla.com/D125610
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
Inline `Set.prototype.has` in CacheIR when called with objects.
Implementing `MacroAssembler::hashObject()` on 32-bit platforms is difficult,
because it uses 64-bit operations, so we either have to allocate twice as much
registers for `Register64` or alternatively spill the values on the stack. For
now just punt and only support this optimisation on 64-bit platforms.
Differential Revision: https://phabricator.services.mozilla.com/D118977
Inline `Set.prototype.has` in CacheIR when called with objects.
Implementing `MacroAssembler::hashObject()` on 32-bit platforms is difficult,
because it uses 64-bit operations, so we either have to allocate twice as much
registers for `Register64` or alternatively spill the values on the stack. For
now just punt and only support this optimisation on 64-bit platforms.
Differential Revision: https://phabricator.services.mozilla.com/D118977
Inline `Set.prototype.has` in CacheIR when called with objects.
Implementing `MacroAssembler::hashObject()` on 32-bit platforms is difficult,
because it uses 64-bit operations, so we either have to allocate twice as much
registers for `Register64` or alternatively spill the values on the stack. For
now just punt and only support this optimisation on 64-bit platforms.
Differential Revision: https://phabricator.services.mozilla.com/D118977
On some systems, uint_fast8_t may be as big as size_t! So the `static_assert(sizeof(aIndex) < sizeof(size_t))` could fail there. The better test here is to check for the expected type (uint_fast8_t).
Now, since uint_fast8_t can be bigger than 8 bits, we may as well choose it for variant sizes greater than 255, up to UINT_FAST8_MAX.
(The added parentheses help clang-format distinguish '<' for tests vs for templates.)
Differential Revision: https://phabricator.services.mozilla.com/D119574
When advancing to Beta, we stop adding sentinels after serialized data
in IPC::Message objects. These sentinels would cause all Extract calls
to not reach the end of the message buffer on Nightly. This patch fixes
an assertion failure which can occur when extract calls fully empty the
buffer, and the finished iterator is advanced by 0 bytes.
Differential Revision: https://phabricator.services.mozilla.com/D118838
This should improve the performance of large calls to AdvanceAcrossSegments
when using a very large BufferList, as we no longer need to iterate over each
element to find the destination when the call is closer to the end.
This will be used most frequently with the new footer code to seek to the end
of an IPC message to read out the footer.
Differential Revision: https://phabricator.services.mozilla.com/D116667
This unfortunately requires a new method to be added to BufferList to
support truncating the buffer to a particular iterator.
Differential Revision: https://phabricator.services.mozilla.com/D116666
This should improve the performance of large calls to AdvanceAcrossSegments
when using a very large BufferList, as we no longer need to iterate over each
element to find the destination when the call is closer to the end.
This will be used most frequently with the new footer code to seek to the end
of an IPC message to read out the footer.
Differential Revision: https://phabricator.services.mozilla.com/D116667
This unfortunately requires a new method to be added to BufferList to
support truncating the buffer to a particular iterator.
Differential Revision: https://phabricator.services.mozilla.com/D116666
This is much simpler and lets us tidy up the addProperty code more. It also makes
it easier to change ShapeTable for property maps in the future.
Lookup performance and memory usage appear to be similar for the two versions,
probably because ShapeTable used the same double-hashing algorithm and because
we can purge most ShapeTables on GC.
Differential Revision: https://phabricator.services.mozilla.com/D113089
Allow using the MOZ_KnownLive function to get around it.
Use case is the following: I have an std::function member variable, and I want
that member to be able to capture `this`.
Using a strong reference creates a cycle and thus would leak. I know `this` to
always outlive the member, so it is fine to use a weak capture there.
Differential Revision: https://phabricator.services.mozilla.com/D111850
WASI lacks of support many memory stuff like mmap, memory protections and etc, but
it has malloc so we can use it instead. Also, here we are stubbing out all
uses of the missing WASI memory functionality.
Differential Revision: https://phabricator.services.mozilla.com/D110075
WASI lacks of support many memory stuff like mmap, memory protections and etc, but
it has malloc so we can use it instead. Also, here we are stubbing out all
uses of the missing WASI memory functionality.
Differential Revision: https://phabricator.services.mozilla.com/D110075
Also make CompactPair<A, B> a literal type if A and B are literal types,
and add MaybeStorageBase that ought to be used as a basis of MaybeStorage
in a follow-up patch.
Differential Revision: https://phabricator.services.mozilla.com/D55930
A long standing issue is that MOZ_ASSERT and related don't print stack
traces in debug builds when they're directly or indirectly emitted from
non-libxul code. Moving WalkTheStack to mozglue alleviates the problem.
It's also not printing stack traces when emitted from C code (and for
some C third party libraries, we do redirect assert to MOZ_ASSERT),
which we solve by making the corresponding API available without C++
(which WalkTheStack being a static method of the nsTraceRefCnt class
didn't allow, or the use of a closure on Android).
This requires some adjustements to headers that indirectly assume that
Assertions.h includes ErrorList.h through nsError.h through nscore.h
through nsTraceRefcnt.h.
We also remove TestStackCrawl.cpp because it hasn't been built since
bug 158528, 19 years ago.
Differential Revision: https://phabricator.services.mozilla.com/D108913