This makes the hash table used for tracking ZoneAllocPolicy generic and able to track memory owned by other non-GC things. The idea is to use this for tracking the memory associated with shared array buffers in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D55533
--HG--
extra : moz-landing-system : lando
This patch adds a python script to update #includes from V8 to SM, and runs the script over each of the V8 source files. This automates 90%+ of the changes that are necessary to prepare V8 source for inclusion in SM. The remaining changes will come in a subsequent patch. Almost all of those changes simply involve adding a shim #include in the right place.
Differential Revision: https://phabricator.services.mozilla.com/D51930
--HG--
extra : moz-landing-system : lando
Irregexp is the V8 regular expression engine. SpiderMonkey contains a heavily modified copy of a previous version of irregexp (under js/src/irregexp). The modifications make it very difficult to incorporate upstream changes. To catch up on webcompat, we are re-importing a fresh copy of irregexp, with the intent of tracking upstream more closely.
This patch imports the source files that can be found here:
2599d3cc20/src/regexp
... with the following files removed:
regexp/OWNERS
regexp/regexp.cc
regexp/regexp-utils.cc
regexp/regexp-utils.h
regexp/regexp-macro-assembler-arch.h
regexp/ia32/*
regexp/x64/*
regexp/mips/*
regexp/mips64/*
regexp/arm/*
regexp/arm64/*
regexp/s390/*
regexp/ppc/*
In addition, a VERSION file has been added pointing to the most recently imported V8 github revision, and js/src/new-regexp has been added to the list of directories covered by the V8 license in licenses.html.
Differential Revision: https://phabricator.services.mozilla.com/D51928
--HG--
extra : moz-landing-system : lando
The eagerBoundsCheck variable was desynchronized from compiler feature support
for bulk memory operations, namely for Cranelift. This manually checks for
Cranelift usage, and this will need to be reverted once bulk memory opcodes
support land in Cranelift.
Differential Revision: https://phabricator.services.mozilla.com/D55683
--HG--
extra : moz-landing-system : lando
The holdings objects can be foreground or background finalized, but HeapPtr's destructor depends on the referent's arena to have not been released. Making FinalizationGroups foreground finalized achieves this.
Differential Revision: https://phabricator.services.mozilla.com/D55302
--HG--
extra : moz-landing-system : lando
Where a FinalizationGroup and its target are in different compartments they are linked by a CCW from a map in the target's zone to the FinalizationGroup. This deals with what happens if we nuke the CCWs between these two compartments. I think the sensible thing to do in this case is to not call the FinalizationGroup's callback and effectively forget about the registrations. Nuking CCWs happens when compartments are known to be dead and therefore this is similar to the way don't call callbacks on shutdown.
Depends on D55114
Differential Revision: https://phabricator.services.mozilla.com/D55115
--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
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
Jon Coppeard
Tooru Fujisawa
Jim Blandy
Bogdan Tara
Iain Ireland
Deian Stefan
Tom Ritter
Benjamin Bouvier
Edgar Chen
Logan Smyth
Coroiu Cristina
Matthew Gaudet
Ted Campbell
Steve Fink
André Bargull
Chris Fallin