This should clarify why they are unsafe.
Also rename the overlong 'unsafeUnbarrieredForTracing' to 'unbarrieredAddress'
to be more like Rooted::address and since it is used outside of tracing in a
couple of places.
Differential Revision: https://phabricator.services.mozilla.com/D89012
This moves the default barrier implementations for the pre and read barriers to
the Cell base class and combines the existing post barrier implemenations in to
a single function.
Differential Revision: https://phabricator.services.mozilla.com/D89011
This testcase is a bit fragile to changes in warmup thresholds. It might be nice if we added a testing function to trial-inline a function on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D89215
This happens when using the logger on youtube.com.
The written CacheIR code is not actually valid when writing failed, so we crash.
Differential Revision: https://phabricator.services.mozilla.com/D89195
The bug here occurs when we:
a) Trial-inline A into B, creating an ICScript owned by B with a pointer to A's JitScript.
b) Perform a compacting GC, discarding the JitScript for A, but preserving the JitScript for B (because it is on the stack).
c) Create a new JitScript for A.
d) Warp-compile B, without hitting the B->A trial-inlined call IC.
In this case, the `JitScript*` stored in the ICScript created in `a)` is dangling, and does not match the JitScript created in `c)`.
The easy way to fix this is to not store a `JitScript*` here in the first place. We only use `ICScript::jitScript_` to:
a) Tell whether the ICScript is inlined, which can be done more easily by looking at the depth.
b) Find the `FallbackICStubSpace` for non-inlined ICScripts.
If we use the depth to tell when an ICScript is inlined, then we don't need a pointer to find the owning JitScript (and therefore its stub space) for non-inlined ICScripts. Non-inlined ICScripts are embedded inside a JitScript, so we can compute the offset directly.
Differential Revision: https://phabricator.services.mozilla.com/D88690
This patch was generated by running:
```
perl -p -i \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF8toUTF16\((.*)\);/\1CopyUTF8toUTF16(\3, \2);/;' \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF16toUTF8\((.*)\);/\1CopyUTF16toUTF8(\3, \2);/;' \
$FILE
```
against every .cpp and .h in mozilla-central, and then fixing up the
inevitable errors that happen as a result of matching C++ expressions with
regexes. The errors fell into three categories:
1. Calling the convert functions with `std::string::c_str()`; these were
changed to simply pass the string instead, relying on implicit conversion
to `mozilla::Span`.
2. Calling the convert functions with raw pointers, which is not permitted
with the copy functions; these were changed to invoke `MakeStringSpan` first.
3. Other miscellaneous errors resulting from over-eager regexes and/or the
replacement not being type-aware. These changes were reverted.
Differential Revision: https://phabricator.services.mozilla.com/D88903
This stores slots/element ranges as object and start index rather than having
two separate representations (one used during marking, one when we yield to the
mutator during marking). It's possible that this could affect marking
performance but we'll catch that by checking the mark rate telemetry. This
should also reduce the size needed for the mark stack a little.
Differential Revision: https://phabricator.services.mozilla.com/D88723
This stores slots/element ranges as object and start index rather than having
two separate representations (one used during marking, one when we yield to the
mutator during marking). It's possible that this could affect marking
performance but we'll catch that by checking the mark rate telemetry. This
should also reduce the size needed for the mark stack a little.
Differential Revision: https://phabricator.services.mozilla.com/D88723
On real hardware, when a background thread finishes compilation, it must signal
to the other executing threads that they need to reload a new version of the
code. Ideally, each executing thread would run an ISB instruction to do so. We
hereby use a system call membarrier that interrupts every other running thread,
and will cause the same effect as a local ISB would. It is heavyweight, so we
make sure to only run it in the case where we're on a background thread.
In the simulator, pending icache flushing requests were never satisfied before
this patch, when the request was emitted from a thread other than the main
thread. Similar behavior as above is emulated.
Differential Revision: https://phabricator.services.mozilla.com/D88395
This adds an OOL path to handle null/undefined => globalThis without a VM call.
IonBuilder optimizes that case based on TI and this ensures we're not a lot slower
for that.
Also give the MIR instruction an empty AliasSet so we can optimize it better in
inlined functions. We no longer have the thisValue hook mentioned in the comment.
Differential Revision: https://phabricator.services.mozilla.com/D88974
Initially the plan was to reuse TraceCacheIRStub but this patch adds the tracing
code for Warp separately because:
* CacheIR stub data in Warp contains nursery indexes. It's nice to keep that out of the IC-tracing code.
* We can use WarpGCPtr similar to other snapshotted GC pointers. It asserts GC things are not moved.
Differential Revision: https://phabricator.services.mozilla.com/D88965
Longer-term more CompileInfo fields should be moved into WarpSnapshot, we can
then dump these fields.
Depends on D88963
Differential Revision: https://phabricator.services.mozilla.com/D88964
Use TODO(post-Warp) for TODOs that can only be addressed when IonBuilder is gone.
Remove some TODOs that are no longer relevant or don't need to be addressed
short-term.
Depends on D88961
Differential Revision: https://phabricator.services.mozilla.com/D88962
Allowlisting this op in the checker is wrong because we don't want a
MagicValue to show up for JSOp::ToString in Baseline.
Depends on D88960
Differential Revision: https://phabricator.services.mozilla.com/D88961
The ones in maybeInlineIC have been addressed. The one about extra var environments
isn't really a TODO for Warp specifically.
Also change the stub data copying to just use nullptr if there's no stub data.
This is fairly common for simpler IC stubs.
Differential Revision: https://phabricator.services.mozilla.com/D88960