The dom::TypedArray type currently represents its length as uint32_t. Changing
that to size_t/uint64_t would cause problems (truncation) for many 'Length()' callers.
Instead of requiring a length check for each of those call sites, for now check for
and reject large array buffers and views in the generated bindings.
Code and tests are based on the implementation of the [AllowShared] attribute.
Additional tests for the new JSAPIs will be added as part of bug 1674777.
Depends on D102911
Differential Revision: https://phabricator.services.mozilla.com/D102912
The pref is only checked on startup and sets a process-wide flag, so that we
don't have to worry about the value changing from under us.
Differential Revision: https://phabricator.services.mozilla.com/D102911
Currently we arrange for the low thre bits of the TraceKind value be set for all trace kinds greater than seven (see definition of JS::TraceKind). This is to save a branch creating a GCCellPtr in GCCellPtr::checkedCast.
This has the side effect of generating an 80 entry lookup table when we switch on TraceKind when there are only 12 distinct trace kinds. And clang doesn't use a branch in checkCast anyway.
The patch changes TraceKind so that the values increment by one each time. This affects performance by increasing inlining opportunities in the marking code.
Depends on D103501
Differential Revision: https://phabricator.services.mozilla.com/D103502
One thing we have to do when tracaing is udpate context information (e.g. edge name) if the tracer is a kind that requires it. It's simpler and more efficient to give all tracers this context and perform an unconditional write to the stack.
Mostly we can get away without saving/restoring context information too. This adds AutoClearTracingContext for the one place we need to do this because of nested use of the same tracer while tracing something else.
Differential Revision: https://phabricator.services.mozilla.com/D103500
This patch does several things:
- make the counter type int64_t like the work budget parameter (the original purpose of this bug)
- simplify implementation by using a Variant to discriminate between different kinds of budget
- remove the global initialization
- remove makeUnlimited() (and replace uses with assignment from SliceBudget::unlimited())
- add convenience methods to get the original budget parameters
- add basic API tests
The use of Variant had the consequence that we now have to pass SliceBudget by reference now to make the linter happy.
Differential Revision: https://phabricator.services.mozilla.com/D103318
Previously we always said "Trying to read" even when the error occurred while
trying to write.
The use of "object" in the new messages is inaccurate when the user is trying
to set a private field on a primitive value, but this is the best I can do
without adding fields to the error message--which would have to affect
bytecode.
Differential Revision: https://phabricator.services.mozilla.com/D100258
This doesn't change the current defaults, only the comments and default values which were wrong/misleading - see the current call to setGCMode() in the GCRuntime constructor.
Differential Revision: https://phabricator.services.mozilla.com/D102717
This renames the data structures inside Chunk:
ChunkInfo -> TenuredChunkInfo
PerArenaBitmap -> DecommitBitmap
ChunkBitmap -> MarkBitmap
ChunkBase -> TenuredChunkBase
This also renames TenuredChunkBase::bitmap to markBits.
Depends on D102394
Differential Revision: https://phabricator.services.mozilla.com/D102395
Currently the decommit task uses Chunk's next pointer to for a singly linked list of chunks awaiting decommit. This is kind of dubious since they are supposed to be NurseryChunks at this point.
This changes the decommit task to use a vector and simplifies the threading requirements by having us always wait for the previous decommit to finish before starting a new one.
Depends on D102393
Differential Revision: https://phabricator.services.mozilla.com/D102394
The ChunkLocation field is not necessary because we can tell the different between nursery chunks and tenured heap chunks based on whether the storebuffer pointer is null or not. This patch removes the field.
Jan, is there any impact on the generated JIT code for doing it this way?
This allows us to get one more arena per chunk on 64 bit systems with the small chunk size.
Differential Revision: https://phabricator.services.mozilla.com/D102393
Remove the unnecessary padding. This lets us have one more arena per chunk on 32 bit Android builds with the small chunk size.
Differential Revision: https://phabricator.services.mozilla.com/D102392
This patch makes ChunkBitmap::getMarkWordAndMask into an instance method so that the uses in MarkingValidator access the correct bitmap.
Depends on D101778
Differential Revision: https://phabricator.services.mozilla.com/D102207
This moves the chunk metadata to the start of the chunk and defines the data structures in the public header. This simplifies accessing this data and removes the need for hardcoded offsets.
Requesting review from jandem for JIT updates.
Differential Revision: https://phabricator.services.mozilla.com/D101778
All integral to NumberValue conversions are now handled by the setNumber template,
except for NumberValue(uint32_t) which has to stay constexpr to not add static
constructors to the DOM bindings when compiling with GCC.
This ensures setNumber(x) and NumberValue(x) behave consistently.
Remove unnecessary setMagic/setNumber implementations from HeapBase: the setMagic
implementation was wrong (would always assert) and they should just be inherited
from the base class.
Differential Revision: https://phabricator.services.mozilla.com/D102184
`for-of` loops mustn't start with the token sequence `async of`, because that
leads to a shift-reduce conflict when parsing `for (async of => {};;)` or
`for (async of [])`. This restriction doesn't apply to `for-await-of` loops,
because `async` in `for await (async of ...)` is always parsed as an identifier.
Parsing `for (async of ...)` already results in a SyntaxError, but that happens
because `assignExpr()` always tries to parse the sequence `async [no LineTerminator] of`
as the start of an async arrow function. That means `forHeadStart()` still needs
to handle the case when `async` and `of` are separated by a line terminator.
Part 3 will update the parser to allow `for await (async of ...)`.
Spec change: https://github.com/tc39/ecma262/pull/2256
Depends on D100994
Differential Revision: https://phabricator.services.mozilla.com/D100995
Instead of using both an optional out-param and a boolean return value, we
can simply return the token directly. This is less error-prone and requires
no change to callers that did not use the out-param.
Differential Revision: https://phabricator.services.mozilla.com/D101654
This simplifies tracing by removing the special case for the tenuring tracer in
TraceEdgeInternal. TenuringTracer becomes a GenericTracer and this path uses
virtual dispatch.
Most tenuring is not done by this path however and the compiler can optimise
away the virtual dispatch in the TenuringTracer::traverse methods.
I measured around 15% improvement for evicting a full nursery in local
benchmarking with this change.
Differential Revision: https://phabricator.services.mozilla.com/D100876
This rearranges a few things so that we can run a minor GC inside a major GC
slice, so we don't have to be conservative about collecting the nursery at the
start of a slice.
Differential Revision: https://phabricator.services.mozilla.com/D99366
Update TypedArray [[DefineProperty]] to match the current spec. This includes
throwing in `js::DefineTypedArrayElement` for out-of-bounds indices and
detached buffers. V8 already ships with this behaviour, so it should be
web-compatible for us to throw errors. We can't reuse the existing
`JSMSG_BAD_INDEX` error code, because that throws a `RangeError`.
As a side-effect of this change, `Object.seal()` will now throw non-empty
TypedArrays.
Differential Revision: https://phabricator.services.mozilla.com/D99382
This rearranges a few things so that we can run a minor GC inside a major GC
slice, so we don't have to be conservative about collecting the nursery at the
start of a slice.
Differential Revision: https://phabricator.services.mozilla.com/D99366
Following on from the previous patch which moved the individual flags for the
zone kind into shadow::Zone, we can replace these by a single kind enum which
is set once when the zone is created.
Depends on D99782
Differential Revision: https://phabricator.services.mozilla.com/D99787
The problem here is that we can trigger this barrier when background
finalization destroys HeapPtrs to things in the atoms zone, since the atoms
zone may still be marking at this point. (Usualy cross-zone edges are stored in
the private pointer of a cross-compartment wrapper.)
To avoid the possiblity of races the patch checks the current thread when the
target thing is in the atoms zone. To make this work without pulling the whole
of Zone.h into Cell.h I had to move some of the zone's flags into shadow::Zone.
I'll tidy that a little in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D99782
The TrySkipAwait opcode optimization is challenging to JIT compile because of
the complicate semantics of its return values. In order to make this
dramatically more simple to JIT implement, this patch splits TrySkipAwait into
two ops: `CanSkipAwait` and `MaybeExtractAwaitValue`.
The first op, `CanSkipAwait` does the preparation to ensure that it would be
legal to skip the await enqueue. The second op, `MaybeExtractAwaitValue` uses
the result of the `CanSkipAwait` to decide if it should leave the value alone
or instead replace it with the awaited value. This pair of ops is a bit easier
for Warp to model in MIR than a single op.
Differential Revision: https://phabricator.services.mozilla.com/D98756
This adds a new background task for unmarking which gets kicked off in the
first GC slice. There's a new explicit 'prepare' state for both the GCRuntime
and zones. The GC proper starts in a second (or later) slice when this has
finished. Because of this we have to be a bit careful when checking GC
state because the 'prepare' state is not part of the GC from the point of view
of snapshot-at-the-beginning.
I had to update a bunch of test code that assumed that GC started in the mark
state.
This fixes cancelleling a parallel task in the case that the task was idle so
that it doesn't leave the cancel flag set.
Also it stops us sending telemetry about how much was collected in GCs that
were reset as we don't always have the data for the original heap sizes by this
point if the reset happened while we were in the prepare phase.
Finally there's a new zeal mode to test this, named YieldBeforeRootMarking
(slightly confusing but in line with the other modes).
Differential Revision: https://phabricator.services.mozilla.com/D98481
Introduce a mechanism for experimenting with unary and binary SIMD
instructions (x64 + ion only, nightly only, and behind flags).
Basically this is useful for performance experiments.
A specific pattern of the first 15 bytes of the mask of the shuffle
opcode is recognized as a trigger; the last byte has the opcode 0..31.
For unary operations the two input values should be the same; the lhs
will always be chosen. The pattern is recognized during lowering and
translated to specific machine instructions.
This mechanism is preferable to custom opcodes because it allows
existing tools (emscripten/llvm/binaryen/linkers) to be used without
change.
To trigger this, use --wasm-compiler=ion --wasm-simd-wormhole in the
shell or set javascript.options.wasm_baselinejit=false and
javascript.options.wasm_simd_wormhole=true in about:config.
This patch is mostly infrastructure but also introduces three
experimental opcodes: one to test for the presence and operation of
the wormhole, one to invoke the Intel PMADDUBSW instruction, and one
to invoke the Intel PMADDWD instruction.
Differential Revision: https://phabricator.services.mozilla.com/D94101
This adds assertions that zone pointers passed in refer to zones we know about
and adds and API that's called when zones are destroyed. It also adds some
standard assertions for other related APIs.
Differential Revision: https://phabricator.services.mozilla.com/D99071
Introduce a mechanism for experimenting with unary and binary SIMD
instructions (x64 + ion only, nightly only, and behind flags).
Basically this is useful for performance experiments.
A specific pattern of the first 15 bytes of the mask of the shuffle
opcode is recognized as a trigger; the last byte has the opcode 0..31.
For unary operations the two input values should be the same; the lhs
will always be chosen. The pattern is recognized during lowering and
translated to specific machine instructions.
This mechanism is preferable to custom opcodes because it allows
existing tools (emscripten/llvm/binaryen/linkers) to be used without
change.
To trigger this, use --wasm-compiler=ion --wasm-simd-wormhole in the
shell or set javascript.options.wasm_baselinejit=false and
javascript.options.wasm_simd_wormhole=true in about:config.
This patch is mostly infrastructure but also introduces three
experimental opcodes: one to test for the presence and operation of
the wormhole, one to invoke the Intel PMADDUBSW instruction, and one
to invoke the Intel PMADDWD instruction.
Differential Revision: https://phabricator.services.mozilla.com/D94101
This commit removes TypedObject's type system (StructTypeDescr,
ArrayTypeDescr, ScalarTypeDescr) and replaces it with a
wasm::TypeHandle to a wasm::TypeDef inside the global
wasm::TypeContext. TypeDescr is left as a JSObject that
wraps a wasm::TypeHandle for a TypedObject. In the future
it will likely be re-used for a RttValue.
When instantiating a module, types are transferred to
the global context and TypeDescr objects wrapping the type handles
are created. The TypeDescr objects are placed in TlsData
for the TypeIdDesc corresponding to the StructType.
Differential Revision: https://phabricator.services.mozilla.com/D96223
The major difference between the two separate implementations
of ToJSValue is that the one operating on void* to have
!isExposable() filtered out by callers and generates a plausible
value for !isExposable() values. This allows the function to be
used by the debugger and not trigger errors in functions that have
v128.
This commit unifies both ToJSValue implementations to expect
!isExposable() values filtered out by callers and will return
a plausible value (now 'undefined') for users like debuggers
who want something. All callers that expect an error now check
isExposable() before calling the coercion function.
Differential Revision: https://phabricator.services.mozilla.com/D96221