This is a backout of the change in Bug 1580246 (Remove object-literal
singleton objects allocated at parse).
The change above caused an unexpected performance regression on Kraken,
in particular due to the way that the new parse-time approach to
allocating objects influenced the `ObjectGroup`s of the created objects,
leading to overly-polymorphic ICs in a numeric-heavy benchmark
(`stanford-crypto-aes`).
We'll work on a fix, but in the meantime, we don't want to leave the
slowdown on m-c.
Differential Revision: https://phabricator.services.mozilla.com/D52200
--HG--
extra : moz-landing-system : lando
This change doesn't include the String.prototype.matchAll modifications, because
those are already part of the main spec.
MCallOptimize.cpp:
- The inlining is more conservative than `inlineIsRegExpObject`, because it's not
clear at this point we need the extra features from `inlineIsRegExpObject`.
String.js:
- The self-hosted part is slightly different than the current spec text, because
it combines the match and replace loops. The non-functional replace part is
implemented in C++, so we can reuse the existing C++ matcher functions.
String.cpp:
- Added some extra assertions to `AppendDollarReplacement` and also had to change
the `infallibleAppend` call into a normal `append` call, because when called
from `replaceAll`, we may not have reserved enough space in the StringBuffer.
- `replaceAll` has a specialised implementation when the pattern is the empty
string, because in that case the pattern is interleaved in-between each
character, so we don't need to find the next match and can also directly reserve
the correct string length (when no '$' characters are present in the replacement
string). This should allow users to update from the previous
`str.split("").join(r)` pattern to `str.replaceAll("", r)` without loss of
performance.
- When the pattern isn't the empty string, we reuse the existing `StringMatch`
and `AppendDollarReplacement` functions to match and replace the pattern.
This feature is still restricted to Nightly, because no test262 tests are
currently available.
Differential Revision: https://phabricator.services.mozilla.com/D51842
--HG--
extra : moz-landing-system : lando
Currently restricted to Nightly-only, because the spec PR still contains bugs
and there are no test262 tests for this feature (except for tests to ensure the
properties are retrieved from the options object).
Differential Revision: https://phabricator.services.mozilla.com/D51855
--HG--
extra : moz-landing-system : lando
Use ApplyUnicodeExtensionToTag to add the collation keyword instead of manually
splicing the keyword into the language tag.
Differential Revision: https://phabricator.services.mozilla.com/D51854
--HG--
extra : moz-landing-system : lando
This will allow us to reuse this function to insert the calendar and numberingSystem
options into the locale in part 3.
Differential Revision: https://phabricator.services.mozilla.com/D51853
--HG--
extra : moz-landing-system : lando
The problem is that we change the slice budget after passing it to gcstats::AutoGCSlice. Later on we compare the actual time taken against the old value and think we've overrun our budget. The fix is to make the change earlier.
Depends on D52161
Differential Revision: https://phabricator.services.mozilla.com/D52162
--HG--
extra : moz-landing-system : lando
This was an ambiguity in the spec between the prose and formalism. The spec
interpreter implements it this way.
Differential Revision: https://phabricator.services.mozilla.com/D52130
--HG--
extra : moz-landing-system : lando
This pretty printer wants to traverse a mozilla::detail::HashTable, but the way
that type represents the actual table has changed drastically since the
pretty-printer was last working. The type of the `mTable` member is now `char*`,
and it seems to be an array of hash values concatenated with the actual entries.
Fixing that seems like it will take a significant investment.
I would love to see this brought back from the revision control history and
fixed, but removing it is all I have time for at the moment.
Differential Revision: https://phabricator.services.mozilla.com/D51487
--HG--
extra : moz-landing-system : lando
The pretty-printer expects to find the value of the `NON_NATIVE` flag in
`js::Class`, which doesn't exist any more. That flag is now a static const
member of `JSClass`.
Differential Revision: https://phabricator.services.mozilla.com/D51489
--HG--
extra : moz-landing-system : lando
This commit changes all bulk-memory instructions to perform up-front bounds
checks and trap if any access would be out-of-bounds before writing.
This affects:
* memory.init,copy,fill
* table.init,copy,fill
* data segment instantiation (reduces to memory.init)
* elem segment instantiation (reduces to table.init)
Spec issue: https://github.com/WebAssembly/bulk-memory-operations/issues/111
Differential Revision: https://phabricator.services.mozilla.com/D51755
--HG--
extra : moz-landing-system : lando
