Move the relazification decisions to JSScript since the check is made after
delazification happens. The JSScript::isRelazifiable check inspects
characteristics of the script itself, while JSScript::canRelazify includes
additional checks for runtime conditions outside the script.
Depends on D55362
Differential Revision: https://phabricator.services.mozilla.com/D55390
--HG--
extra : moz-landing-system : lando
Now that both LazyScript and JSScript have the same pointer field, we can
move to the BaseScript class. The inner-function pointers in the gcthings
array will have the same meaning for both LazyScript and JSScript, but the
other members of gcthings may have different interpretations.
This adds poisoning of the PrivateScriptData in the LazyScript case for
consistency.
Depends on D55361
Differential Revision: https://phabricator.services.mozilla.com/D55362
--HG--
extra : moz-landing-system : lando
Reorder the classes in JSScript.h so that we can use PrivateScriptData from
within BaseScript.
Depends on D55360
Differential Revision: https://phabricator.services.mozilla.com/D55361
--HG--
extra : moz-landing-system : lando
It it straight-foward for users of LazyScriptData to support a single array
for closedOverBindings and innerFunctions. As a result, we can use
PrivateScriptData as the implementation and eliminate the LazyScriptData type
altogether.
Depends on D55035
Differential Revision: https://phabricator.services.mozilla.com/D55360
--HG--
extra : moz-landing-system : lando
Unify the JSScript::warmUpData_ and LazyScript::enclosingLazyScriptOrScope_
fields into BaseScript. As a script progresses from lazy up to being JIT-ed
it the type stored in this field will change. If a script is in a compiled
state, the enclosingLazyScriptOrScope_ value can always be reconstructed
during relazification.
Depends on D55034
Differential Revision: https://phabricator.services.mozilla.com/D55035
--HG--
extra : moz-landing-system : lando
Allow storing manually-barriered GC pointers in ScriptWarmUpData. This
updates the 'trace' method as needed. When switching types, the user must
first 'clear' the old type and then 'init' the new type. We continue to use
WarmUpCount(0) as the default safe state.
Depends on D55033
Differential Revision: https://phabricator.services.mozilla.com/D55034
--HG--
extra : moz-landing-system : lando
Prepare to move the warmUpData field to BaseScript by first moving the type
definition earlier in the file.
Differential Revision: https://phabricator.services.mozilla.com/D55033
--HG--
extra : moz-landing-system : lando
Removes rooting when the allocation isn't followed by any operation which can
GC resp. takes a `JSContext` argument.
Differential Revision: https://phabricator.services.mozilla.com/D54769
--HG--
extra : moz-landing-system : lando
Subtraction doesn't have the same unused malloc memory problem which was present
for addition and subtraction, so the relative speed-up when adding a uint64
fast-path is less prominent (only about 10%), but it still seems worthwhile to
provide a fast-path, too.
Differential Revision: https://phabricator.services.mozilla.com/D54768
--HG--
extra : moz-landing-system : lando
`absoluteCompare()` is currently called twice when subtracting two BigInts,
avoiding the second call gives a slight speed-up.
Differential Revision: https://phabricator.services.mozilla.com/D54767
--HG--
extra : moz-landing-system : lando
An earlier part changed the `digit` function to be `const`, so we can now make
these two functions `const`, too.
Differential Revision: https://phabricator.services.mozilla.com/D54765
--HG--
extra : moz-landing-system : lando
We never define `HAVE_INT128_SUPPORT`, so the uint128 code path is never
enabled. Change the test to use `__SIZEOF_INT128__` to enable it on
applicable platforms.
Differential Revision: https://phabricator.services.mozilla.com/D54762
--HG--
extra : moz-landing-system : lando
Similar to the previous part, also add a fast-path when multiplying two Bigints
which fit into uint64_t. When the result also fits into uint64_t, this approach
avoids allocating unused malloc memory.
Differential Revision: https://phabricator.services.mozilla.com/D54761
--HG--
extra : moz-landing-system : lando
Add a fast path for uint64 BigInts to `BigInt::absoluteAdd`. This fast path
gives a substantial speed-up, because addition for uint64 BigInts no longer
needs allocate malloc memory when the result also fits into uint64_t.
Differential Revision: https://phabricator.services.mozilla.com/D54760
--HG--
extra : moz-landing-system : lando
Adds `fitsInUint64` to check if a BigInt fits into uint64_t and `uint64FromNonZero`
to extract an uint64_t value from a non-zero BigInt. Boths function are inline
because the next patches will use them in fast-paths.
Differential Revision: https://phabricator.services.mozilla.com/D54759
--HG--
extra : moz-landing-system : lando
Resolves the TODO in `destructivelyTrimHighZeroDigits` and additionally removes
`trimHighZeroDigits`, because it is no longer used. This change is especially
beneficial for functions which are most of the time over-estimating the result
digit length, like for example `BigInt::absoluteAdd`.
Differential Revision: https://phabricator.services.mozilla.com/D54758
--HG--
extra : moz-landing-system : lando
This allows to use these functions without pulling in the complete `jsnum.h` header.
Differential Revision: https://phabricator.services.mozilla.com/D54757
--HG--
rename : js/src/jsnum.h => js/src/util/CheckedArithmetic.h
extra : moz-landing-system : lando
This change passes through the "inner singleton" status of a particular
object literal to the group-assignment logic for JSOP_NEWOBJECT by
instead using a variant opcode, JSOP_NEWOBJECT_WITHGROUP. "Inner
singleton" status is meant to emulate old behavior (prior to ObjLiteral)
in which the frontend built an entire tree of objects/arrays with a
top-level singleton. In the old world, these objects were allocated by
ParseNode::getConstantValue() in the frontend and built by
ObjectGroup::newPlainObject, which looked up an object group by property
names. In the new world, the default NEWOBJECT logic uses a separate
test for whether an allocation site should have a singleton group, and
even after we carefully emulate the old group behavior in the frontend,
the new-object allocation itself will decide to allocate singleton
groups. In the particular regression case motivating this change, these
singleton groups break the TI information for a singleton array (typeset
for all elems no longer has a single group) and as a result, a simple
property access can no longer be inlined. This patch matches the old
behavior and allows the inlining to occur.
Differential Revision: https://phabricator.services.mozilla.com/D54609
--HG--
extra : moz-landing-system : lando
This patch extends the "inner singleton" hack to array element object
literals in the parser. With the new ObjLiteral system, we are
attempting to emulate the old (sometimes incidental) behavior of the
parser's literal object allocation as closely as possible, to avoid
regressions (such as this bug). The "inner singleton" status indicates
that an object would have been allocated as part of a tree objects, with
a singleton at the top, in the old world. In this case, we do something
slightly different with the group setup. The second half of this patch
will extend the inner-singleton bit back through to object allocation
during execution.
Differential Revision: https://phabricator.services.mozilla.com/D54236
--HG--
extra : moz-landing-system : lando
None of these uses actually need this header. Mostly they need the definitions in GC-inl.h.
Differential Revision: https://phabricator.services.mozilla.com/D55437
--HG--
extra : moz-landing-system : lando
This adds the shell option for all the FinalizationGroup tests and updates the test262 update script. We still need to run the update script so that the tests do feature detection.
Differential Revision: https://phabricator.services.mozilla.com/D55121
--HG--
extra : moz-landing-system : lando
The patch adds a new option that can be used from jstests.list to pass additional shell command line options. With feature detection (skip-if) this allows us to have tests running on infra for experimental features that are not yet supported in the browser.
Differential Revision: https://phabricator.services.mozilla.com/D54316
--HG--
extra : moz-landing-system : lando
`StoreBuffer::putSlot` when called with a nursery object as its `obj` parameter
is a no-op, because `StoreBuffer::put` is a no-op when `Edge::maybeInRememberedSet`
return false, which, in the case of `SlotsEdge`, happens when `SlotsEdge::object()`
is in the nursery. This enables us to skip the linear traversal of the elements
array in `elementsRangeWriteBarrierPost` when the current object is in the nursery.
Differential Revision: https://phabricator.services.mozilla.com/D55420
--HG--
extra : moz-landing-system : lando
Move the relazification decisions to JSScript since the check is made after
delazification happens. The JSScript::isRelazifiable check inspects
characteristics of the script itself, while JSScript::canRelazify includes
additional checks for runtime conditions outside the script.
Depends on D55362
Differential Revision: https://phabricator.services.mozilla.com/D55390
--HG--
extra : moz-landing-system : lando
Now that both LazyScript and JSScript have the same pointer field, we can
move to the BaseScript class. The inner-function pointers in the gcthings
array will have the same meaning for both LazyScript and JSScript, but the
other members of gcthings may have different interpretations.
This adds poisoning of the PrivateScriptData in the LazyScript case for
consistency.
Depends on D55361
Differential Revision: https://phabricator.services.mozilla.com/D55362
--HG--
extra : moz-landing-system : lando
Reorder the classes in JSScript.h so that we can use PrivateScriptData from
within BaseScript.
Depends on D55360
Differential Revision: https://phabricator.services.mozilla.com/D55361
--HG--
extra : moz-landing-system : lando
It it straight-foward for users of LazyScriptData to support a single array
for closedOverBindings and innerFunctions. As a result, we can use
PrivateScriptData as the implementation and eliminate the LazyScriptData type
altogether.
Depends on D55035
Differential Revision: https://phabricator.services.mozilla.com/D55360
--HG--
extra : moz-landing-system : lando
Coroiu Cristina
Matthew Gaudet
Ted Campbell
Steve Fink
André Bargull
Chris Fallin
Noemi Erli
Ciure Andrei
Jon Coppeard
Ryan Hunt
Tom Ritter
Mu Tao