This creates some macros so the field headings and format data are all stored
in a central place.

Differential Revision: https://phabricator.services.mozilla.com/D168432

Differential Revision: https://phabricator.services.mozilla.com/D168423

This makes it so you can just call trace() on it. The barriers should not end
up being triggered anyway.

Differential Revision: https://phabricator.services.mozilla.com/D168227

MruCache is used for Latin1Char* strings which are serialized from JSRopes without
need to call ensureLinear().

Differential Revision: https://phabricator.services.mozilla.com/D167490

Bug 1811934 - Have nsID::ToString() return an managed string instead of a raw pointer r=xpcom-reviewers,nika

And use nsID::ToProvidedString(...) method when suitable.

This naturally fixes a memory leak in dom/fetch/FetchParent.cpp.

Differential Revision: https://phabricator.services.mozilla.com/D167606

Backed out changeset 7d4b830c1cf6 (bug 1811934) for causing wpt failures on pointerevent_pointerrawupdate_in_pointerlock.html CLOSED TREE

I assumed that this would have been covered in ValueNumbering.cpp, but it
appears this is a one-of-a-kind foldsTo, in that every other one either folds
to an existing node or to a constant?

Differential Revision: https://phabricator.services.mozilla.com/D168128

Bug 1811934 - Have nsID::ToString() return an managed string instead of a raw pointer r=xpcom-reviewers,nika

And use nsID::ToProvidedString(...) method when suitable.

This naturally fixes a memory leak in dom/fetch/FetchParent.cpp.

Differential Revision: https://phabricator.services.mozilla.com/D167606

Depends on D168288

Differential Revision: https://phabricator.services.mozilla.com/D168289

This was added in this [1] commit, but the actual purpose and intent have been
lost, though the comment has nevertheless survived.

[1]: https://hg.mozilla.org/mozilla-central/rev/251540232d8f8890458446fcb2e89f8a87b02cd7

Differential Revision: https://phabricator.services.mozilla.com/D168288

The Dart Barista-3 benchmark creates around 662,000 wasm-gc arrays.  Of these,
308,000 have no elements (bizarrely); as a result we end up malloc-heap
allocating a zero-sized payload area for them.  It would be better not to.

This patch changes WasmArrayObject::createArray so as to allocate the data
area only if the number of elements is non-zero.  As a result the invariant
for WasmArrayObject "data pointer is never null" is changed to "data pointer
is null iff the number of elements is zero".  But that's no big deal.

::obj_trace and ::obj_finalize are updated accordingly.

Differential Revision: https://phabricator.services.mozilla.com/D168239

Bug 1795255 - autofix duplicate imports in tests under docshell, dom, layout, security, testing, toolkit and widget, r=Standard8,webdriver-reviewers

Differential Revision: https://phabricator.services.mozilla.com/D167715

The Dart Barista-3 benchmark gives the initial expression interpreter a lot of
work.  Profiling shows that wasm::InitExprInterpreter::stack heap-allocates
around 37000 short-lifetime blocks to hold the stacked values.  Using a
48-element inline capacity removes all of those allocations. (40 removes
almost all, but not all).

Similar ridealong fix: for the wasm parser iterator Iter<Policy>::valueStack_,
increase inline capacity from 16 to 32.  This takes out another 2500
allocations.

Differential Revision: https://phabricator.services.mozilla.com/D167926

XPCNativeWrapper may be going away (bug 1481337). Stop defining it in the main environments and only define it
where necessary to discourage more uses.
This also helps to clarify the ESLint test environment globals.

Differential Revision: https://phabricator.services.mozilla.com/D168211

Depends on D168025

Differential Revision: https://phabricator.services.mozilla.com/D168189

Bug 1375505, which introduced GuardAndGetIterator, has two microbenchmarks in the comments, testing monomorphic and small-N polymorphic cases. Both of those are faster if we remove GuardAndGetIterator and just use ObjectToIterator: the polymorphic case goes from 190-220ms to 165-175ms, and the monomorphic case goes from 140-160ms to 125-135ms.

Disabling GuardAndGetIterator gives about a 1% improvement on Speedometer 2, largely on the back of a 2-3% improvement on React/React-Redux.

Differential Revision: https://phabricator.services.mozilla.com/D168025

The only other place where we get the return value from a rematerialized frame is in OnLeaveIonFrame. The top level frame obviously can't be a generator. I tried and failed to write a testcase that would force a return from a top-level Ion frame, but we always seem to bail out to baseline first. I'm not convinced it's possible; if it is, then eventually the fuzzer will figure out a testcase.

Differential Revision: https://phabricator.services.mozilla.com/D168174

Differential Revision: https://phabricator.services.mozilla.com/D168177

Differential Revision: https://phabricator.services.mozilla.com/D167765

Differential Revision: https://phabricator.services.mozilla.com/D167764

Differential Revision: https://phabricator.services.mozilla.com/D167682

Backed out changeset 9985617f2b96 (bug 1812895) for causing SM bustages on CacheIRGenerator.h CLOSED TREE

Bug 1375505, which introduced GuardAndGetIterator, has two microbenchmarks in the comments, testing monomorphic and small-N polymorphic cases. Both of those are faster if we remove GuardAndGetIterator and just use ObjectToIterator: the polymorphic case goes from 190-220ms to 165-175ms, and the monomorphic case goes from 140-160ms to 125-135ms.

Disabling GuardAndGetIterator gives about a 1% improvement on Speedometer 2, largely on the back of a 2-3% improvement on React/React-Redux.

Differential Revision: https://phabricator.services.mozilla.com/D168025

After some discussion, we came to the conclusion that this code still needs to exist, but the comment is misleading. Hopefully this describes the justification better.

Depends on D168001

Differential Revision: https://phabricator.services.mozilla.com/D168002

Differential Revision: https://phabricator.services.mozilla.com/D168001

Differential Revision: https://phabricator.services.mozilla.com/D167927

Bug 1811809: Use non-signalling Neg instruction for MacroAssembler::neg32, neg64, and negPtr. r=jandem

The condition flags needed to be set before we had `branchNeg32`, but now that
`branchNeg32` is present, the normal `neg32` operation can use `Neg` instead
of `Negs`.

Differential Revision: https://phabricator.services.mozilla.com/D167525

Differential Revision: https://phabricator.services.mozilla.com/D167994

Differential Revision: https://phabricator.services.mozilla.com/D167882

Differential Revision: https://phabricator.services.mozilla.com/D167855

Bug 1812380 - Replace refereces to 'work stealing' with 'work requesting' in parallel marking implementation r=sfink

This also changes the method to move work between mark stacks to take |src| and
|dst| arguments to make it clearer what's happening.

Differential Revision: https://phabricator.services.mozilla.com/D167935

Differential Revision: https://phabricator.services.mozilla.com/D167870

Similar to the Discard marker, it seems useful to have a profile marker for
discard events since they can toss a lot of Jit code.

Differential Revision: https://phabricator.services.mozilla.com/D167896

Port  D167359 D166265 and D166899 to riscv64

Differential Revision: https://phabricator.services.mozilla.com/D167901

Differential Revision: https://phabricator.services.mozilla.com/D167899

Bug 1812055 - Add fast paths for the most common cases to JSStructuredCloneReader::readObjectField. r=sfink

On typical workloads, these fast paths for plain objects and array objects handle
at least 97% of cases. This is much faster than the generic `DefineDataProperty` code.

Differential Revision: https://phabricator.services.mozilla.com/D167685

Making this more like other ion optimization flags.

Depends on D167733

Differential Revision: https://phabricator.services.mozilla.com/D167734

We sort to avoid complications with enumeration hooks, but if there are valid indices, then we know there aren't any enumeration hooks.

Differential Revision: https://phabricator.services.mozilla.com/D167733

Currently non-parallelizable workloads can perform worse with parallel marking
enabled, particularly with more than two threads. This is because we end up
stealing very frequently when there is no advantage to doing so and this
interrupts marking progress.

I tested several approaches to fixing this but the one that worked best was
simply to disallow stealing from very small stacks.

Depends on D167783

Differential Revision: https://phabricator.services.mozilla.com/D167784