To be able to remove SystemGroup, NS_ReleaseOnMainThreadSystemGroup
needs to have its dependency on SystemGroup removed. Since all
releases using SystemGroup would've released on the main thread anyway
we can safely replace NS_ReleaseOnMainThreadSystemGroup with
NS_ReleaseOnMainThread.
Depends on D64390
Differential Revision: https://phabricator.services.mozilla.com/D67631
--HG--
extra : moz-landing-system : lando
By having CollectPerformanceInfo traverse the BrowsingContextGroup and
tree of BrowsingContexts we can hide the task of getting the DocGroups
befind an API in BrowsingContextGroup and ease the removal of
TabGroups.
Differential Revision: https://phabricator.services.mozilla.com/D64390
--HG--
extra : moz-landing-system : lando
Use self.log more consistently in runxpcshelltests.py (print is still used in main()).
Differential Revision: https://phabricator.services.mozilla.com/D70037
--HG--
extra : moz-landing-system : lando
For many years now this has covered all our JIT codegen, not just Ion, so this is
a lot less confusing. Using --enable-ion/--disable-ion now results in an error that
suggests the new name.
Differential Revision: https://phabricator.services.mozilla.com/D69579
--HG--
extra : moz-landing-system : lando
These days we can get the same information by checking JS_CODEGEN_NONE, so let's
do that.
Differential Revision: https://phabricator.services.mozilla.com/D69578
--HG--
extra : moz-landing-system : lando
This patch introduces a new DLL blocklist type `RedirectToNoOpEntryPoint`
which hooks a DLL's entrypoint into a no-op function. With this technique,
we give the injected DLL no chance to run its code though we allow it to be
loaded into the process.
This new blocklist type is intended to block a DLL which is injected by IAT
patching which was planted by a kernel callback routine for LoadImage. It's
because blocking such a DLL makes a new process fail to launch.
Differential Revision: https://phabricator.services.mozilla.com/D68348
--HG--
extra : moz-landing-system : lando
This patch introduces `Kernel32ExportsSolver` which calculates RVAs of
kernel32's functions and transfers them to a target process, where the
transferred RVAs are resolved into function addresses.
Depends on D68346
Differential Revision: https://phabricator.services.mozilla.com/D68347
--HG--
extra : moz-landing-system : lando
This patch introduces a new DLL interceptor `WindowsDllEntryPointInterceptor`
which applies a hook to a target function without backing up the original
function code.
Depends on D68345
Differential Revision: https://phabricator.services.mozilla.com/D68346
--HG--
extra : moz-landing-system : lando
This patch introduces a new policy `MMPolicyInProcessEarlyStage` which does
not consume any functions imported from kernel32.dll so that we can use it
in a process's early stage i.e. before IAT is resolved.
Depends on D68344
Differential Revision: https://phabricator.services.mozilla.com/D68345
--HG--
extra : moz-landing-system : lando
`WindowsDllDetourPatcher::CreateTrampoline` does not only create a trampoline
region but also applies a patch on an original function. This patch extracts
the patching part as separate functions.
Depends on D68343
Differential Revision: https://phabricator.services.mozilla.com/D68344
--HG--
extra : moz-landing-system : lando
This patch moves the instantiation of `PEHeaders` from `CheckBlockInfo` to
`IsDllAllowed` so that `IsDllAllowed` can use an instance of `PEHeaders`.
Depends on D68342
Differential Revision: https://phabricator.services.mozilla.com/D68343
--HG--
extra : moz-landing-system : lando
This patch introduces `nt::VirtualQuery` which consumes only ntdll's functions
to reduce dependency in `MMPolicy` on kernel32.dll. With this, `MMPolicy` still
depends on kernel32.dll, that will be solved by a coming patch.
Differential Revision: https://phabricator.services.mozilla.com/D68342
--HG--
extra : moz-landing-system : lando
We cache this information in compatibility.ini so we can just expose it on
nsIXULRuntime.
Differential Revision: https://phabricator.services.mozilla.com/D66112
--HG--
extra : moz-landing-system : lando
We don't put system addons on the blocklist so there's no need to compute
blocklist state for them. The immediate motivation for this is to avoid
initializing the blocklist early in startup for the initial startup in a
new profile or after a browser upgrade when we're installing/udpating
system and builtin addons.
Differential Revision: https://phabricator.services.mozilla.com/D68443
--HG--
extra : moz-landing-system : lando
They're supposed to be the same, though right now they are black on white
because only highlight was overridden via prefs.
I'll fix the bugs I found yesterday in a separate bug.
Depends on D69939
Differential Revision: https://phabricator.services.mozilla.com/D69940
--HG--
extra : moz-landing-system : lando
This doesn't change behavior, just makes the color return what we set right now
via prefs in mobile/android/app/mobile.js.
Differential Revision: https://phabricator.services.mozilla.com/D69938
--HG--
extra : moz-landing-system : lando
Same deal as with the previous parts, changes `MBitNot` to always specialise as
`Int32` and removes any code which handled non-Int32 specialisation.
Differential Revision: https://phabricator.services.mozilla.com/D69800
--HG--
extra : moz-landing-system : lando
Noticed while working on the previous part:
`js::UrshOperation()` is marked as `MOZ_ALWAYS_INLINE`, but these callers don't
need to use the inlined version and instead should use `js::UrshValues()`.
Differential Revision: https://phabricator.services.mozilla.com/D69799
--HG--
extra : moz-landing-system : lando
Removes the codegen support for non-number binary bitwse instructions.
The if-statements conditions in `Lowering.cpp` were changed to test `ins->type()`
instead of `lhs->type()` to match the binary arithmetic lowering code.
Differential Revision: https://phabricator.services.mozilla.com/D69798
--HG--
extra : moz-landing-system : lando
'MBinaryBitwiseInstruction` is now only used for number specialisations, so we
can remove any non-number specialisation code.
Differential Revision: https://phabricator.services.mozilla.com/D69797
--HG--
extra : moz-landing-system : lando
Remove `MBinaryBitwiseInstruction::specializeAs()` and instead directly set the
specialisation in the `MBinaryBitwiseInstruction` constructor.
For BitAnd, BitOr, and BitXor also set the "commutative" flag in the constructor.
Differential Revision: https://phabricator.services.mozilla.com/D69796
--HG--
extra : moz-landing-system : lando
Similar to the earlier `MBinaryArithInstruction` changes, directly set the number
specialisation when constructing a `MBinaryBitwiseInstruction` node.
That way we no longer have to call `setInt32Specialization()` and
`setCommutative()` manually after constructing a binary bitwise instruction.
Differential Revision: https://phabricator.services.mozilla.com/D69795
--HG--
extra : moz-landing-system : lando
Similar to `MAdd::NewWasm` and `MSub::NewWasm` from earlier patches,
add a separate `MUrsh::NewWasm` function to handle wasm-specific
initialisation for `MUrsh`.
That frees up the `MUrsh(MDefinition, MDefinition, MIRType)` constructor to
only set the specialisation without performing any wasm-specific actions.
Differential Revision: https://phabricator.services.mozilla.com/D69794
--HG--
extra : moz-landing-system : lando
The different `infer()` overrides were all testing that the operands are
"simple bit-operands", but as demonstrated in the last part, we were no longer
calling `infer()` with non-simple bit-operands.
Instead let's effectively inline `infer()` and set the appropriate flags for
the individual MIR nodes:
- BitAnd, BitOr, BitXor: `MBinaryBitwiseInstruction::specializeAs()` isn't a
public method, so we have to call `setInt32Specialization()` and
`setCommutative()` separately. (At least for now, later patches will clean
this up.)
- Lsh and Rsh: Call `setInt32Specialization()` to set the return type and the
specialisation, similar to what happened in `MShiftInstruction::infer()`.
- Ursh: Add `MUrsh::setDoubleSpecialization()` as a temporary mean to set the
Double specialisation. Otherwise handle it similar to Lsh and Rsh.
Differential Revision: https://phabricator.services.mozilla.com/D69793
--HG--
extra : moz-landing-system : lando
Inline `binaryBitOpEmit()` into `binaryBitOpTrySpecialized()`. This makes it
easier to see that both operands are "simple bit-operands" when applying this
optimisation.
This change is useful for the next part, which will remove
`MBinaryBitwiseInstruction::infer()`, because `infer()` also tests that the
operands are "simple bit-operands".
Differential Revision: https://phabricator.services.mozilla.com/D69792
--HG--
extra : moz-landing-system : lando
`IonBuilder::binaryBitOpEmit()` is always called with `specialization == Int32`,
so we can remove the specialisation parameter and instead directly handle it
within `binaryBitOpEmit()`.
Differential Revision: https://phabricator.services.mozilla.com/D69791
--HG--
extra : moz-landing-system : lando
MBinaryArithInstruction no longer uses non-number specialisations, so we can
remove the codegen support for it.
Differential Revision: https://phabricator.services.mozilla.com/D69790
--HG--
extra : moz-landing-system : lando
Update callers which modify the MBinaryArithInstruction specialisation to use
`setSpecialization()`, which asserts the new specialisation is definitely a
number type.
Differential Revision: https://phabricator.services.mozilla.com/D69789
--HG--
extra : moz-landing-system : lando
The last part ensures that MBinaryArithInstruction always uses a number
specialisation, so we can now remove any code which handles non-number
specialisations for MBinaryArithInstruction.
Differential Revision: https://phabricator.services.mozilla.com/D69788
--HG--
extra : moz-landing-system : lando
Set the specialisation and the return type directly in `MBinaryArithInstruction`.
Also assert that the specialisation is definitely a number type.
Differential Revision: https://phabricator.services.mozilla.com/D69787
--HG--
extra : moz-landing-system : lando
`MAdd`, `MSub`, `MMul`, `MDiv`, and `MMod` are no longer called without a
number specialisation, so we can remove these constructors.
Differential Revision: https://phabricator.services.mozilla.com/D69785
--HG--
extra : moz-landing-system : lando
Instead of manually adjusting the specialisation in `IonBuilder::binaryArithEmitSpecialized()`,
directly pass it to `MBinaryArithInstruction::New()`.
The constructor changes in the previous parts made it possible to pass `MIRType`
to the `MAdd` and `MSub` constructors.
Differential Revision: https://phabricator.services.mozilla.com/D69783
--HG--
extra : moz-landing-system : lando
The new `MAdd` and `MSub` constructors with a `MIRType` argument can be used
in these places to directly set the return type and the specialisation. That
way we no longer have to call `setInt32Specialization()` manually.
`MMul` already has a compatible constructor which the desired semantics, so
we can remove the `setInt32Specialization()` call here, too.
Differential Revision: https://phabricator.services.mozilla.com/D69781
--HG--
extra : moz-landing-system : lando
Similar to the previous part, add `MSub::NewWasm` to handle the wasm-specific
initialisation bits, so that `MSub(MDefinition, MDefinition, MIRType)` only
sets the return type and the specialisation.
Differential Revision: https://phabricator.services.mozilla.com/D69780
--HG--
extra : moz-landing-system : lando
Add `MAdd::NewWasm` similar to how we have a separate `MMul:NewWasm` function.
For wasm we want to default to `MDefinition::Truncate` and set the "commutative"
flag for Int32 values.
This frees up the `MAdd(MDefinition, MDefinition, MIRType)` to only set the
specialisation and the return type, which will be required for later patches to
work correctly.
Differential Revision: https://phabricator.services.mozilla.com/D69779
--HG--
extra : moz-landing-system : lando
Later patches will require a constructor with the signature
`MAdd(MDefinition, MDefinition, MIRType)`, which neither sets the truncation
mode nor sets the "commutative" flag. Both things happen with the existing
constructor which has a compatible signature and which is currently called
for the use sites modified in this patch. (The existing constructor is the
one directly appearing before the newly added one.)
The existing constructor defaults to `MDefinition::Truncate` and all callers to
that constructor use the `MIRType::Int32` specialisation. Because all callers
use `MIRType::Int32`, we can omit the type parameter for the new constructor.
The existing constructor is also called from WasmIonCompile, the next part will
handle that caller.
Differential Revision: https://phabricator.services.mozilla.com/D69778
--HG--
extra : moz-landing-system : lando
Ion doesn't use ICs for bit-not `~` with String inputs, which resulted in
`+int32AsString` being noticeably faster than `~~int32AsString`. Handling
string indices makes `~~int32AsString` faster than the IC code, which is what
we'd normally expect.
Drive-by change:
- Reuse `SimpleBitOpOperand()` for `bitnotTrySpecialized()`.
Differential Revision: https://phabricator.services.mozilla.com/D69519
--HG--
extra : moz-landing-system : lando
- `emitGuardAndGetNumberFromString()` was changed to use `ScratchDoubleScope`,
because `FloatReg0` isn't available for Unary ICs. (Lowering doesn't reserve it.)
- `unaryArithTrySpecializedOnBaselineInspector()` now needs to filter String
values to avoid bailouts.
Differential Revision: https://phabricator.services.mozilla.com/D69518
--HG--
extra : moz-landing-system : lando
Directly convert Strings to Int32 to make `+int32AsString` faster and to be
able to have narrower type information for Ion/Warp. Without this change the
unary String ICs for Int32 results from the next part are actually slower than
the ICs for Double results.
`emitGuardAndGetInt32FromString()` is based on the existing
`emitGuardAndGetNumberFromString()` method.
Differential Revision: https://phabricator.services.mozilla.com/D69517
--HG--
extra : moz-landing-system : lando
I've went with `LoadInt32Result` and `LoadDoubleResult` to match the existing
`LoadObjectResult` CacheIR opcode.
The arguments `jsop_binary_arith()` in `IonBuilder::jsop_pos()` needed to be
swapped to match the requirements in `arithUnaryBinaryCache()`.
Differential Revision: https://phabricator.services.mozilla.com/D69516
--HG--
extra : moz-landing-system : lando
`tryAttachNumber()` can actually assert the result is a number when the input
is a number.
Differential Revision: https://phabricator.services.mozilla.com/D69515
--HG--
extra : moz-landing-system : lando
vm/Interpreter-inl.h:
- `IncOperation()` and `DecOperation()` should use a non-mutable handle for their
`val` parameter.
vm/Interpreter.cpp:
- It's not necessary to create two mutable handles for the same input value.
jit/BaselineIC.cpp:
jit/IonIC.cpp:
- Only when caling `BitNot()` and `NegOperation()` we need to copy the input value.
Differential Revision: https://phabricator.services.mozilla.com/D69514
--HG--
extra : moz-landing-system : lando
