While refactoring this code, upstream V8 removed their own need to have `Isolate` as a friend class of `RegExpStack`. We need to be able to reach inside RegExpStack for a couple of reasons, so we use `ExternalReference`, which is still a friend class (to support ExternalReference::TopOfRegExpStack, which is used in V8's macroassembler code).
Since ExternalReference already exists, I'm also using it for the memory accounting code.
Differential Revision: https://phabricator.services.mozilla.com/D152907
IsCharacterInRangeArray is translated from the version in `imported/regexp-macro-assembler.h`, with more comments and adjustments to make callWithABI work.
Differential Revision: https://phabricator.services.mozilla.com/D152905
This patch changes the x86/x64 backend to:
- avoid unaligned write of int32_t, unaligned read of uintptr_t values.
- replace typed pointer arithmetic by byte offsets only.
- add comments with opcode when patching assembly.
Differential Revision: https://phabricator.services.mozilla.com/D153597
Dictionary slots currently never shrink: when removing properties we put the slots
on the dictionary free list. If we know there are no slotful properties left, however,
we can free the slots and reset the free list.
This is mostly nice for densifying because we can usually free all slots in that case.
The patch also fixes a minor issue in `NativeObject::shrinkSlots`, because this code
is now used for dictionary objects for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D153437
The power-of-two heuristic in `maybeDensifySparseElements` doesn't work well if
we're getting slots from the slot free list, because in that case the slot span
can be the same power-of-two for a long time and adding elements becomes
quadratic.
This patch avoids the problem by only trying to densify if we're using the last
slot. That still handles the common initialization pattern this code was written
to handle.
Differential Revision: https://phabricator.services.mozilla.com/D153436
These flags are usually initialized very early on, but because child processes are
pre-allocated and then later specialized for a specific process type, we need to
reset them later. This patch adds a new API for this that has some extra assertions.
Differential Revision: https://phabricator.services.mozilla.com/D152373
BacktrackingAllocator.{h,cpp} contain a few functions whose names are vague or
misleading or both. This patch renames four such functions. There is no
functional change.
BacktrackingAllocator::splitAndRequeueBundles
-> BacktrackingAllocator::updateVirtualRegisterListsThenRequeueBundles
BacktrackingAllocator::resolveControlFlow
-> BacktrackingAllocator::createMoveGroupsFromLiveRangeTransitions
BacktrackingAllocator::reifyAllocations
-> BacktrackingAllocator::installAllocationsInLIR
LiveRange::distributeUses
-> LiveRange::tryToMoveDefAndUsesInto
Differential Revision: https://phabricator.services.mozilla.com/D153348
Calculate the allocation rate per zone. This requires remembering the previous
heap size and also tracking the amouth of memory freed in the mean time.
This uses an exponential moving average to smooth the result but with a much
lower factor, so that the allocation rate decays slowly when a zone stops
allocating.
Differential Revision: https://phabricator.services.mozilla.com/D152866
This estimates the collection rate per zone based on GC time (including
off-thread sweeping) and zone size pre-GC. The result is smoothed using an
exponential moving average.
We don't have per-zone time information for main thread GC time, so we estimate
proportionally based on the zone's initial size. The patch records per-zone
sweeping time and includes that in the calculation. Compacting time is not
included since that is relatively rare and will skew the result.
Differential Revision: https://phabricator.services.mozilla.com/D152865
This makes sure we still set the module state to evaluated when there's an
uncatchable exception. The module's error will be set to undefined, which is
not great but it will probably never be used in this case.
Differential Revision: https://phabricator.services.mozilla.com/D153372
We were using the activation's exitFP for this, but that value isn't cleared
when we return to JIT code from C++ so we could use stale values if we're in JIT
code (or used `callWithABI` calls without an exit frame). This could result in
unsymbolicated frames or missing frames in profiles.
This patch changes the JIT and Wasm frame iterators to set `endStackAddress` from
their constructor. In the outer iterator we then keep track of the first value for
the current activation and use that instead of the activation's exitFP.
Adds an assertion to the single-step callback to check `frame.endStackAddress >= state.sp`
in simulator builds. This failed on many jit-tests before this patch and passes now.
Differential Revision: https://phabricator.services.mozilla.com/D153214
WASI uses extra JSContext fields to track the recursion depth.
Given WASI doesn't support thread, move it to JSContext and
MainThreadErrorContext.
Depends on D152781
Differential Revision: https://phabricator.services.mozilla.com/D152782
FoldVisitor is subclass of RewritingParseNodeVisitor, which has
JSContext* field. and FoldVisitor doesn't have to have the same field.
Depends on D152776
Differential Revision: https://phabricator.services.mozilla.com/D152777
`parent` parameter is used only internally.
Remove `parent` parameter from public methods.
This simplifies the stack limit parameter in the next patch.
Depends on D152774
Differential Revision: https://phabricator.services.mozilla.com/D152775
Move the stack limit calculation around principal into `JSContext` method,
so that some consumer can pre-calculate it and feed it to
`AutoCheckRecursionLimit`.
Depends on D152772
Differential Revision: https://phabricator.services.mozilla.com/D152773
The shell module loader was rewritten to C++ in bug 1637529.
"jsrtfuzzing-example.js" was changed to appease prettier, now that it's enabled.
Differential Revision: https://phabricator.services.mozilla.com/D153151
It's now simpler to use the counter on the zone directly. It also no longer needs
to be an atomic because we only get/set it on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D153145
This improved the time for a contrived benchmark. I don't know if we want
to invest more time into benchmarking - I feel pretty strongly that this will
be an improvement across most use cases, just judging from the more in-depth
benchmarking of the string functions. The benchmark I did was basically as
follows:
make N arrays
make N objects
for i,j in 0..N,0..N
if (hash(i,j) % K == 0)
arrays[i].push(objects[j])
start performance timer
for i,j in 0..N,0..N
if arrays[i].includes(objects[j])
matches++
report matches and performance timings
And our times were basically equal for small N, and up to 3 times faster
for large N - so, basically what we would hope for.
Differential Revision: https://phabricator.services.mozilla.com/D152298
While refactoring this code, upstream V8 removed their own need to have `Isolate` as a friend class of `RegExpStack`. We need to be able to reach inside RegExpStack for a couple of reasons, so we use `ExternalReference`, which is still a friend class (to support ExternalReference::TopOfRegExpStack, which is used in V8's macroassembler code).
Since ExternalReference already exists, I'm also using it for the memory accounting code.
Differential Revision: https://phabricator.services.mozilla.com/D152907
IsCharacterInRangeArray is translated from the version in `imported/regexp-macro-assembler.h`, with more comments and adjustments to make callWithABI work.
Differential Revision: https://phabricator.services.mozilla.com/D152905
If the top activation is a C++ interpreter activation, the code would incorrectly use
`nullptr` as `lastProfilingFrame` for the first `JitActivation`.
Differential Revision: https://phabricator.services.mozilla.com/D153061
This commit updates our decoding/validation for the removal of runtime
types. This means that instructions that produce rtt values are now
removed. Instructions that consumed rtt values, such as struct.new_with_rtt
are renamed and no longer take rtt values. There is no agreed upon
spec for the renames, but the validation of the instructions is generally
agreed upon.
Most churn comes from the removal of ValType::Rtt. Tests are updated in
a later commit.
This commit depends on a pending change in upstream wasm-tools [1]. A
commit to update our vendored version will be added before this lands.
[1] https://github.com/bytecodealliance/wasm-tools/pull/677
Differential Revision: https://phabricator.services.mozilla.com/D151405
This adds a shell function 'clearModules' to clear all loaded modules, so that
tests can be insulated from one another.
Depends on D151834
Differential Revision: https://phabricator.services.mozilla.com/D151835
As per the lastest spec this now stays true after evaluation.
This patch keeps a very similar implemenatation and resets the field after
evaluation, except that we now report this special value as true rather than
false. We assert if we try and use get the sort order after this has happened.
We also reset the runtime counter in the same way as before.
Differential Revision: https://phabricator.services.mozilla.com/D151833
This lets us replace relatively slow TLS lookups with a simple dereference.
This also removes the realm from `JitContext`. The runtime still has a few uses
in the MIR backend.
Depends on D152849
Differential Revision: https://phabricator.services.mozilla.com/D152850
`MacroAssembler` now has a single constructor, instead of three different ones
before this patch stack.
Depends on D152847
Differential Revision: https://phabricator.services.mozilla.com/D152848
This follows the Wasm code and prepares for (a) removing the second `MacroAssembler`
constructor and (b) removing the allocator from `JitContext`.
Depends on D152846
Differential Revision: https://phabricator.services.mozilla.com/D152847
This removes some old code to tag debug spew with an ID per assembler, based on a
counter stored in `JitContext`. Usually there's only one assembler per `JitContext` and
we were also not using this for Wasm compilations (it always used id 0), so this
patch removes it.
Depends on D152766
Differential Revision: https://phabricator.services.mozilla.com/D152846
With this patch we always pass a non-null allocator to the `JitContext` constructor,
and then never change it. Use references instead of pointers to make this clearer.
This lets us clean up more code: `AutoJitContextAlloc` can be removed and the
`MacroAssembler` no longer needs the constructor to optionally instantiate that
class.
Differential Revision: https://phabricator.services.mozilla.com/D152765
One of the `MacroAssembler` constructors instantiates a `JitContext` lazily, but
it's simpler to require the callers to create a `JitContext`.
Differential Revision: https://phabricator.services.mozilla.com/D152763
A long time ago, `JitContext` was also used for entering JIT code, but now we only
use it for the compiler backend where we don't need to support nesting.
This requires some minor changes to avoid having multiple active contexts on the
stack, but makes it easier to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D152762
The baldrdash integration of Cranelift is agreed between SM and CL
to be the wrong shape. Our import of the code base is also old and
causes difficulties for us when upgrading some crates (see bug
1774829). We should remove it for now to unblock bug 1774829.
Differential Revision: https://phabricator.services.mozilla.com/D152806
Most of the GC things typically stored in a `JS::Value` can be nursery allocated now,
so using `isGCThing` should result in more compact code with fewer branches.
Barriers in JIT code are already doing something similar since bug 1636916.
Differential Revision: https://phabricator.services.mozilla.com/D152651
These instructions are for `callContentFunction` and `constructContentFunction`
in self-hosted JS, to notify possible native call to debugger in the later
patches.
Differential Revision: https://phabricator.services.mozilla.com/D152345
Use `callContentFunction` even if `this` value is `undefined`.
Use `constructContentFunction` even if `newTarget` value is constructor itself.
Differential Revision: https://phabricator.services.mozilla.com/D152344
This improved the time for a contrived benchmark. I don't know if we want
to invest more time into benchmarking - I feel pretty strongly that this will
be an improvement across most use cases, just judging from the more in-depth
benchmarking of the string functions. The benchmark I did was basically as
follows:
make N arrays
make N objects
for i,j in 0..N,0..N
if (hash(i,j) % K == 0)
arrays[i].push(objects[j])
start performance timer
for i,j in 0..N,0..N
if arrays[i].includes(objects[j])
matches++
report matches and performance timings
And our times were basically equal for small N, and up to 3 times faster
for large N - so, basically what we would hope for.
Differential Revision: https://phabricator.services.mozilla.com/D152298
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
Moving recordErrors in DelazifyTask::Create() to after the allocation of the
task allows us to use the ErrorContext in the task to store the errors instead
of having to move them into the task later, and we only miss the allocation of
the task itself (which wasn't recorded in the errors anyway).
Differential Revision: https://phabricator.services.mozilla.com/D151878
hadErrors() is more descriptive than `errors().empty()`.
Access to the pending errors list is pushed down to OffThreadErrorContext,
because that's the only context where it is used.
Differential Revision: https://phabricator.services.mozilla.com/D151669
This removes a lot of plumbing allocators through function parameters but still
maintains the ErrorContext and allocator as separate concepts.
At this point, there is no need for the type or instances of ErrorContext and
ErrorAllocator to vary independently.
Differential Revision: https://phabricator.services.mozilla.com/D151610
ErrorAllocator was only ever used with ErrorContext, so no need for templating.
linkWithJSContext() better describes what it is doing, since JSContext needs its
errors_ field filled in, at least until we can replace it with a different
allocator for functions that are called during compilation.
getAllocator() is a convenience so we don't have to add a separate allocator
parameter everywhere we pass an ErrorContext and also need an allocator.
Differential Revision: https://phabricator.services.mozilla.com/D151609
ReportErrorVA(), ReportErrorNumberVA(), and ReportErrorNumberUCArray(), and
ReportErrorNumberUTF8Array() use JSContext for rooting, so they will have to be
called from the main thread. The only reason to pass ErrorContext to them would
be for consistency with the other error reporting functions.
Differential Revision: https://phabricator.services.mozilla.com/D151608
ErrorAllocator is an adapter that allows MallocProvider to delegate
to polymorphic Contexts. MallocProvider provides a well-known interface,
but doesn't support polymorphism, so we resort to templating and adapters
like this.
JS::CharsToNewUTF8CharsZ() needs a definition in CharacterEncoding.cpp,
so for now I explicitly instantiate it for ErrorAllocator<JSContext>.
A better solution would be to move the definition to a header, but that's
a bigger task.
Differential Revision: https://phabricator.services.mozilla.com/D151179
OffThreadErrorContext::setAllocator() needs to setOffThreadFrontendErrors on
the JSContext because CompileToStencilTask::parse() uses it to allocate the
CompilationInput.
Differential Revision: https://phabricator.services.mozilla.com/D150647
I could get rid of OffThreadErrorContext::cx_ by subclassing from
MallocProvider, but I don't think that would work since
OffThreadErrorContext has a vtable and MallocProvider does a
static_cast to get the client pointer.
OffThreadFrontendErrors moved to ErrorContext.h to avoid
recursive header inclusion.
Differential Revision: https://phabricator.services.mozilla.com/D150645
Fixes jit-test. Probably needs coordination with ESMification efforts.
It looks like JS::CompileModule() would be called from the main thread, so
it should use GeneralErrorContext.
Differential Revision: https://phabricator.services.mozilla.com/D151178
DummyTokenStreams created when handling RegEx should be happening at JS
runtime, so on main thread (unless maybe workers?); so GeneralErrorContext is
appropriate there.
Differential Revision: https://phabricator.services.mozilla.com/D150644
This allows the Parser creator to provide the ErrorContext appropriate
for the situation (main thread or helper thread). For now, we just use
a flexible implementation.
I think the lifetime of the ErrorContext is the same as the Parser, so
putting the ErrorContext on the stack when the Parser is, too, should be
safe.
Differential Revision: https://phabricator.services.mozilla.com/D150642
Temporarily passing JSAllocator* to ExpandErrorArgumentsVA in
ReportCompileWarning(). It is only used for allocation and for AutoSuppressGC.
Differential Revision: https://phabricator.services.mozilla.com/D150641
The paradigm for DEBUG is that it is defined or not defined, not 1 or 0,
so we have to use ifdef here. Otherwise we get a build error in embedded
SpiderMonkey when DEBUG is not defined.
Differential Revision: https://phabricator.services.mozilla.com/D152556
When installing embedded SpiderMonkey, we need to install the generated
header ProfilingCategoryList.h into /usr/include/mozjs-___/js/ because
that's where the rest of the SpiderMonkey code expects to find it.
It's not automatically installed already, because it's generated.
Thanks to Arai for the suggestion of where to look.
Differential Revision: https://phabricator.services.mozilla.com/D152549
- Add simple tests
- Add validation support for call_ref
- Use typeIndex when function references are enabled
- Add a BaseCompiler::callRef
Differential Revision: https://phabricator.services.mozilla.com/D151727
- Implement MacroAssembler::wasmCallRef
- Extend CalleeDesc and CallSiteDesc
- Add register definition to platforms
- Populate WASM_FUNC_DIRECT_ENTRY_SLOT with funcUncheckedCallEntry address
Tests are provided in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D151772
- Replace all uses of WASM_INSTANCE_OBJ_SLOT, with WASM_INSTANCE_SLOT (which is a Instance* and can access Instance::object_)
- Update JSFunction::trace to trace through WASM_INSTANCE_SLOT, instead of relying on WASM_INSTANCE_OBJ_SLOT
Refactored code is covered by existing tests.
Differential Revision: https://phabricator.services.mozilla.com/D151375
Add PoppedFPJitEntry;
Fix offset when push FrameType and ra in EmitBaselineTailCallVM;
Fix FramePointer in BaselineFrame in generateEnterJIT.
Differential Revision: https://phabricator.services.mozilla.com/D152489
No external caller is using `ToCStringBuf` for a different base than base-10.
This allows to change the buffer size to `JS::MaximumNumberToStringLength`, which
is a multiple of 4 resp. 8, which should be more efficiently to stack allocate
than 34 bytes.
Differential Revision: https://phabricator.services.mozilla.com/D152072
Split both cases in preparation for the next patches.
Drive-by change:
`base = 10` doesn't need to execute the `unsigned(i) < unsigned(base)` and
`unsigned(i) < unsigned(base * base)` cases, because `StaticStrings::hasInt(i)`
covers this case already.
Differential Revision: https://phabricator.services.mozilla.com/D152069
32-bit integers (signed and unsigned) need less space than provided by
`ToCStringBuf` and don't need any dynamically allocated memory, which avoids
calling `ToCStringBuf`'s out-of-line destructor.
Differential Revision: https://phabricator.services.mozilla.com/D152068
`NumberToCStringWithBase` was only ever used with `base = 16`. Adding a dedicated
function for hex-strings enables us to perform more clean-ups in the next patches.
Also change `Int32ToCStringWithBase` to accept signed and unsigned integers. That
way we don't have to convert unsigned integers larger than `UINT32_MAX` to doubles.
Differential Revision: https://phabricator.services.mozilla.com/D152067
Similar to Glean FoG, use types for telemetry metrics. For our existing probes,
this is mainly about using TimeDuration directly. The reported values continue
to be unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D150659
This brings us closer to how both Glean FoG and V8 handle telemetry and lets us
start having better type checking later.
Differential Revision: https://phabricator.services.mozilla.com/D150658
Replace the JS_TELEMETRY_* enums with a JSMetric enum class. Use this to
generate the XPCJSRuntime mapping automatically.
Differential Revision: https://phabricator.services.mozilla.com/D150657
Use TimeDuration more directly in the GC slice telemetry statistics. This
prepares for later patches that add more type safety to telemetry. Measured
values are unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D150656
Update JS telemetry names to match the corresponding Firefox probe names to
avoid any confusion. We usually updated these internal names with _2 suffixes
were added, but not always.
Differential Revision: https://phabricator.services.mozilla.com/D150655
The ArrayBuffer was only reified for the ArrayBuffer constructor optimisation
in `GetBufferSpeciesConstructor`. `GetBufferSpeciesConstructor` was removed in
part 1, so we no longer need this code, too.
Depends on D152266
Differential Revision: https://phabricator.services.mozilla.com/D152267
Remove AllocateArrayBuffer now that it's just an alias for `maybeCreateArrayBuffer`.
Also replace the no longer needed detached check with a release assertion.
Depends on D152265
Differential Revision: https://phabricator.services.mozilla.com/D152266
The previous `js::powi` implementation could cause large floating point
precision errors. For example `(-1.00000041289256280663266807096078991889953613281250000) ** -365287834`
returned `3.1456398721089196e-66` instead of `3.1456398910784315e-66`. This is an
error of 35987774 ULP.
Change `js::powi` as follows:
- Optimise only for non-negative exponents.
- Always optimise when the exponent is `<= 4` to match `MPow::foldsTo`.
- When the exponent is `> 4`, only optimise when the base is an integer. Perform
the whole computation with integer values and when an overflow was detected,
fallback to `std::pow`.
- In all other cases use `std::pow`.
Differential Revision: https://phabricator.services.mozilla.com/D150791
Adding `StringBuffer::append(std::string_view)` would make this more readable,
but the implicit `std::string_view(char*)` constructor could then lead to adding
implicit `strlen` calls, which we try to avoid.
Differential Revision: https://phabricator.services.mozilla.com/D152047
builtin/Object.cpp:
- Using `string_view` avoids the call to `strlen` when `Consume` isn't inlined.
jsapi-tests/testCompileNonSyntactic.cpp:
shell/jsoptparse.cpp:
xpconnect/src/XPCWrappedNativeJSOps.cpp:
- Using `string_view` avoids the `sizeof - 1` pattern.
Depends on D152044
Differential Revision: https://phabricator.services.mozilla.com/D152045
`std::string_view` stores a pointer and its length, so we no longer have to
use two different variables. `std::string_view` methods are also `const_expr`,
so the compiler will inline them at compile-time.
Depends on D152043
Differential Revision: https://phabricator.services.mozilla.com/D152044
Part 1 ensures we generate fast code when comparing against constant `char*`
strings, so we no longer need the more complicated code.
Depends on D152042
Differential Revision: https://phabricator.services.mozilla.com/D152043
This makes the code a bit more uniform.
The previous part should make bug 1589591 obsolete, so it seems useful to make
the code more uniform.
Depends on D152040
Differential Revision: https://phabricator.services.mozilla.com/D152042