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
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's __attribute__((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
Depends on D108344
Differential Revision: https://phabricator.services.mozilla.com/D108345
Because the previous commit changed how MFBT tests are linked, they now
use mozjemalloc. Mozjemalloc randomizes small allocations, which id does
by using MFBT's RandomNum. The code in RandomNum, on mac, uses a system
API that allocates memory. So mozjemalloc has some code to handle the
recursion gracefully.
When the RandomNum test runs, it essentially only runs the RNG... which
goes on to allocate memory, which then goes into the RNG. Needless to
say, that doesn't go well. In typical cases, this is not the type of
things that would happen, but it does happen for that one test.
We work around the issue by allocating memory first, which is actually
hard, because compilers like to optimize unused allocations away. So we
turn the existing code into one that uses an allocation instead of an
array on the stack.
Differential Revision: https://phabricator.services.mozilla.com/D105242
Instead of snprintf.
Because some standalone code uses those functions directly or indirectly,
and PrintfTarget lives in mozglue, they now need to depend on mozglue
instead of mfbt. Except logalloc/replay, which cherry-picks what it
uses, and the updater, for which we keep using vsnprintf.
Differential Revision: https://phabricator.services.mozilla.com/D103730
Because the previous commit changed how MFBT tests are linked, they now
use mozjemalloc. Mozjemalloc randomizes small allocations, which id does
by using MFBT's RandomNum. The code in RandomNum, on mac, uses a system
API that allocates memory. So mozjemalloc has some code to handle the
recursion gracefully.
When the RandomNum test runs, it essentially only runs the RNG... which
goes on to allocate memory, which then goes into the RNG. Needless to
say, that doesn't go well. In typical cases, this is not the type of
things that would happen, but it does happen for that one test.
We work around the issue by allocating memory first, which is actually
hard, because compilers like to optimize unused allocations away. So we
turn the existing code into one that uses an allocation instead of an
array on the stack.
Differential Revision: https://phabricator.services.mozilla.com/D105242
Instead of snprintf.
Because some standalone code uses those functions directly or indirectly,
and PrintfTarget lives in mozglue, they now need to depend on mozglue
instead of mfbt. Except logalloc/replay, which cherry-picks what it
uses.
Differential Revision: https://phabricator.services.mozilla.com/D103730
Instead of snprintf.
Because some standalone code uses those functions directly or indirectly,
and PrintfTarget lives in mozglue, they now need to depend on mozglue
instead of mfbt. Except logalloc/replay, which cherry-picks what it
uses.
Differential Revision: https://phabricator.services.mozilla.com/D103730
This new approach to weak references is roughly modeled after the approach used
by Rust's Arc<T>, and uses an atomic compare-and-swap loop to perform weak to
strong reference upgrades. This approach ends up moving the strong reference
count out of the tracked object and into the weak reference object, as the
strong reference count atomic needs to outlife the object itself.
Rust's Arc Weak::upgrade implementation:
d98d2f57d9/library/alloc/src/sync.rs (L1806-L1837)
Differential Revision: https://phabricator.services.mozilla.com/D102245
This new approach to weak references is roughly modeled after the approach used
by Rust's Arc<T>, and uses an atomic compare-and-swap loop to perform weak to
strong reference upgrades. This approach ends up moving the strong reference
count out of the tracked object and into the weak reference object, as the
strong reference count atomic needs to outlife the object itself.
Rust's Arc Weak::upgrade implementation:
d98d2f57d9/library/alloc/src/sync.rs (L1806-L1837)
Differential Revision: https://phabricator.services.mozilla.com/D102245
Extracts parts of CheckTemporaryStorageLimits into the following new private
member functions of QuotaManager:
* LockedGetOriginInfosExceedingGroupLimit
* LockedGetOriginInfosExceedingGlobalLimit
* GetOriginInfosExceedingLimits
* ClearOrigins
Differential Revision: https://phabricator.services.mozilla.com/D101145
Extracts parts of CheckTemporaryStorageLimits into the following new private
member functions of QuotaManager:
* LockedGetOriginInfosExceedingGroupLimit
* LockedGetOriginInfosExceedingGlobalLimit
* GetOriginInfosExceedingLimits
* ClearOrigins
Differential Revision: https://phabricator.services.mozilla.com/D101145
Extracts parts of CheckTemporaryStorageLimits into the following new private
member functions of QuotaManager:
* LockedGetOriginInfosExceedingGroupLimit
* LockedGetOriginInfosExceedingGlobalLimit
* GetOriginInfosExceedingLimits
* ClearOrigins
Differential Revision: https://phabricator.services.mozilla.com/D101145
Extracts parts of CheckTemporaryStorageLimits into the following new private
member functions of QuotaManager:
* LockedGetOriginInfosExceedingGroupLimit
* LockedGetOriginInfosExceedingGlobalLimit
* GetOriginInfosExceedingLimits
* ClearOrigins
Differential Revision: https://phabricator.services.mozilla.com/D101145
Extracts parts of CheckTemporaryStorageLimits into the following new private
member functions of QuotaManager:
* LockedGetOriginInfosExceedingGroupLimit
* LockedGetOriginInfosExceedingGlobalLimit
* GetOriginInfosExceedingLimits
* ClearOrigins
Differential Revision: https://phabricator.services.mozilla.com/D101145
While at this point PrintfTarget doesn't use double-conversion, add a
test that it can (and thus will) handle the largest double output possible
with the default %f precision.
Differential Revision: https://phabricator.services.mozilla.com/D103431
Bug 608915 switched nsString::AppendFloat to double-conversion, while
handling trailing zero removal on its own. This can be made more
effectively when doing so in double-conversion itself, support for which
was merged upstream in https://github.com/google/double-conversion/pull/149.
This makes the used_exponential_notation outparam unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D102698
As a preparation to remove `index_` field from ParserAtomEntry,
ParserAtomsTable should maintain a map from ParserAtomEntry pointer to
TaggedParserAtomIndex.
Differential Revision: https://phabricator.services.mozilla.com/D102559
Bug 608915 switched nsString::AppendFloat to double-conversion, while
handling trailing zero removal on its own. This can be made more
effectively when doing so in double-conversion itself, support for which
was merged upstream in https://github.com/google/double-conversion/pull/149.
This makes the used_exponential_notation outparam unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D102698
I was running into issues where these names would conflict with the type's own Get/Set methods
and these names have the added benefit of indicating a bit more that atomic stuff is going on.
Differential Revision: https://phabricator.services.mozilla.com/D99268
Add tests to cover the cases when the start iterator is in different segments
and within segments at different positions.
Also assert that `mSegment <= aTarget.mSegment`, so it's more easy to see
that `aTarget` mustn't point to an earlier segment.
Depends on D98340
Differential Revision: https://phabricator.services.mozilla.com/D98462
`as<...>()` on an rvalue variant returns the contained value as rvalue-reference.
`match()` on an rvalue variant forwards the contained value as rvalue-reference.
So now the contained values can be efficiently moved-from.
There are also equivalents for `const&&`, which should be rare.
For `match(2+ matchers)`, the static_assert for same return types has been moved to `Impl::matchN`. Also, it doesn't rely on `FunctionTypeTraits` anymore, which has the added benefit of allowing `auto` in individual matchers.
Differential Revision: https://phabricator.services.mozilla.com/D98050
There are also equivalents for `const&&`, which should be rare.
The small change in `LiveSavedFrameCache::insert` was necessary because `*lookup.framePtr()` now returns an rvalue-ref (as it should).
Differential Revision: https://phabricator.services.mozilla.com/D98049
While all toolkit and js-based projects make use of mfbt, some others,
like tools/crashreporter and tools/update-packaging, don't.
So instead of including mfbt from the top-level directory, include it
from the relevant project top-level mozbuilds.
This allows to remove the dependency on mfbt files in the hash for the
minidump-stackwalk and mar-tools toolchains.
Differential Revision: https://phabricator.services.mozilla.com/D98378
This also adds an UnusedZeroEnum template to Result.h, which can be used
for specializing UnusedZero for scoped enum types.
Differential Revision: https://phabricator.services.mozilla.com/D97074
Poison was setup at the start of xpcom init when that was assumed to be early enough.
Since then, Poison was added to Maybe, and Maybe has been used everywhere, including in
our channel implementation. As a result, poison was being used before it was initialized.
This basically meant our poison pointers were being replaced with null instead, which
dances into some more UB than accessing a page we have actually allocated. Also, tsan
noticed that accesses to the value were racing with the initializer actually being
called!
A (dynamic) static initializer forces the poison initialization as we can reasonably
hope without getting CallOnce or singleton patterns involved.
Other changes:
* Cleaned up the outdated documentation for mozWritePoison (the alignment
restriction was removed in Bug 1414901)
* Removed the poison supression from TSan
Differential Revision: https://phabricator.services.mozilla.com/D94251
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045