This is a reland of fac6f63eb8, after
adding initialization of unused element slots.
Original change's description:
> Use CopyElements (which uses memcpy) to copy FixedDoubleArray.
>
> This improves the performance of ExtractFixedArray and
> CloneFastJSArray for double arrays, which in turn improve the
> performance of cloning double arrays with slice() or spreading.
>
> This, however, does not improve performance of spreading holey
> double arrays, because spreading needs extra work to convert
> holes to undefined.
>
> Bug: v8:7980
> Change-Id: Ib8aed74abbb0b06982a3b754e134fa415cb7de2d
> Reviewed-on: https://chromium-review.googlesource.com/c/1280308
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Commit-Queue: Hai Dang <dhai@google.com>
> Cr-Commit-Position: refs/heads/master@{#56680}
Bug: v8:7980
Change-Id: I899af60c061b9cd6eb619c247c5fc515b92e9fd7
Reviewed-on: https://chromium-review.googlesource.com/c/1382735
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58333}
This changes how rewind upon preparser abort works. It now rewinds to the start
of the parameter scope. In the case of "function X(" it is before the "(". In
the case of arrow functions it's before the start of the arrow function. This
allows us to reparse the arrow function from the start so all parameters are
declared properly.
Bug: v8:2728, v8:7390
Change-Id: I1c40056a49ec198560e63cd73949a59221ee0401
Reviewed-on: https://chromium-review.googlesource.com/c/1382736
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58332}
The SFI's flags can be changed by the mutator while the concurrent marker is checking
the flags for bytecode flushing. None of the flag bits checked for bytecode flushing
are changed, however since they are in an int32 field TSAN will complain if any of the
other flags are changed while reading from another flag. Fix this by making the flags
use the RELAXED_INT32_ACCESSORS.
BUG=v8:8592,v8:8395
Change-Id: I5fbb4fd381c2b288abf0cd36eb0b8256e1929af6
Reviewed-on: https://chromium-review.googlesource.com/c/1382458
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58325}
This CL implements the global.get and global.set instruction for anyref
globals. This includes:
* Properly decode anyref globals.
* Add a FixedArray to WasmInstanceObject to store anyref globals.
* Initialize the FixedArray.
* Generate code for global.get and global set.
This CL does not allow to import globals yet.
R=clemensh@chromium.org
Bug: v8:7581
Change-Id: I62617409271d9b6f2253a191681189865aa1f459
Reviewed-on: https://chromium-review.googlesource.com/c/1380112
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58318}
The parser object can now be created on a worker thread, therefore we shouldn't access
global FLAGs during the constructor. Instead move them to the ParseInfo constructor
and set the parser fields based on these. Also avoid accessing always_opt flags in
bytecode-flags - instead accessing it in ParseInfo and propagating to the bytecode
generator.
Also gets rid of unused kUntrustedCodeMitigations flag in UnoptimizedCompilationInfo
BUG=v8:8582
Change-Id: I6e6fdc8cc7865803cb5f334f652abc0e3e4cb3ce
Reviewed-on: https://chromium-review.googlesource.com/c/1375918
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58316}
Since we always flatten the string upfront, we don't need to
implement the the UTF8 conversion as a string visitor anymore.
R=petermarshall@chromium.org
Bug: v8:6780, v8:8605
Change-Id: I27946551d7c3742f47ac36d5c909c19a7f2b0371
Reviewed-on: https://chromium-review.googlesource.com/c/1371828
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58312}
Since it's explicit what we're tracking, we can immediately throw errors in
certain cases, and ignore irrelevant errors. We don't need to use the
classifier itself to track "let let", since we know whether we're parsing a
"let". Errors that were previously (almost) always accumulated are now
immediately pushed to the scopes that care (parameter initialization errors).
This CL drops avoiding allocation of classified errors, at least for now, but
that doesn't affect performance anymore since we don't aggressively blacklist
anymore. Classified errors are even less likely with the more precise approach.
ParseAssignmentExpression doesn't introduce its own scope immediately, but
reuses the outer scope.
Rather than using full ExpressionClassifiers + Accumulate to separate
expressions/patterns from each other while keeping track of the overall error
state, this now uses an explicit AccumulationScope.
When we parse (async) arrow functions we introduce new scopes
that track that they may be (async) arrow functions.
We track StrictModeFormal parameters in 2 different ways if it isn't
immediately certain that it is a strict-mode formal error: Either directly on
the (Pre)ParserFormalParameters, or on the NextArrowFunctionInfo in the case
we're not yet certain that we'll have an arrow function. In the latter case we
don't have a FormalParameter object yet, and we'll copy it over once we know
we're parsing an arrow function. The latter works because it's not allowed to
change strictness of a function with non-simple parameters.
Design doc:
https://docs.google.com/document/d/1FAvEp9EUK-G8kHfDIEo_385Hs2SUBCYbJ5H-NnLvq8M/
Change-Id: If4ecd717c9780095c7ddc859c8945b3d7d268a9d
Reviewed-on: https://chromium-review.googlesource.com/c/1367809
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58307}
Change the initial value of breakType to undefined
Store break type into bits
Change the algorithm
Bug: v8:6891
Change-Id: Id2cc1e90c28d92364318928fc8a377f172ebb339
Reviewed-on: https://chromium-review.googlesource.com/c/1374996
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58298}
C++ introduces the {alignas} keyword, which can be used with types or
integral constant expressions. Use this instead of the V8_ALIGNAS (for
types) or V8_ALIGNED (for integral constants) macros.
R=ulan@chromium.org
Bug: v8:8562
Change-Id: I54999b56a5715237f88c63d8543ef728a5b2eff5
Reviewed-on: https://chromium-review.googlesource.com/c/1379935
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58290}
Parser::MaybeResetCharacterStream calls Scope::ContainsAsmModule which
recursively checks whether a Scope is an asm module or any of its
sub-scopes. This is sub-optimal for deeply nested scopes and many
functions which do not contain any asm modules.
Drive-by-fix:
- rename Scope::asm_module to Scope::is_asm_module
Change-Id: I922270c608b54c6525f0672ead4aca90f57a6551
Reviewed-on: https://chromium-review.googlesource.com/c/1360636
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58288}
This changes Torque's builtin pointers to use a Smi representation
underneath instead of storing the Code target object. Callsites look
up the target entry point through IsolateData::builtin_entry_table.
The notable effect of this CL is that builtin pointer calls no longer
call any on-heap Code.
Bug: v8:7777
Change-Id: Ibf6c749dd46cae7aba51494b09921229dd436f63
Reviewed-on: https://chromium-review.googlesource.com/c/1379880
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58286}
Either Address* or Handle<Object> or ObjectSlot, depending on
circumstances.
Bug: v8:3770
Change-Id: Id00dfede6eb92ec30b658c0090b5310548ba5162
Reviewed-on: https://chromium-review.googlesource.com/c/1379228
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58282}
New API is here: https://github.com/tc39/proposal-weakrefs/issues/55
The WeakCell parts stay in the old API, resulting in temporary code duplication
in some parts. Those parts will go away once the WeakCell-related parts are
migrated to the new API (but the spec needs some work first).
BUG=v8:8179
Change-Id: I81ca824a14d830e3c5fa515d5ad7e5f78c10e19d
Reviewed-on: https://chromium-review.googlesource.com/c/1378171
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58264}
Enable --harmony-object-from-entries by default.
Object.fromEntries is a new standard library method, whose proposal
(https://tc39.github.io/proposal-object-from-entries/) is currently
at stage 3.
It simply creates a JSObject from an iterable collection of key/value
pairs, such that `Object.fromEntries([ [ "a", "b" ] ]) -> { a: "b" }`
BUG=v8:8021
R=gsathya@chromium.org, adamk@chromium.org
Change-Id: Ib55bb6ca43727d66b471c0fd14845735c1ca2894
Reviewed-on: https://chromium-review.googlesource.com/c/1373918
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58262}
In the process, add the bint type (which stands for Best-INTeger),
which implements Torque's idea of CSA's ParameterMode. It maps to
a different type on 32-bit (Smi) and 64-bit (intptr). There are
convert operators that are either no-ops or conversions
to-and-from Smi and intptrs on the each platform, depending on
the underlying type for bint. This allows Torque code to git most
of the benefits of ParameterMode without having to explicitly
pass around the mode, since it is almost always OptimalMode anyways.
Change-Id: I92e08adc1d79cb3e24576c96f9734aec1af54162
Reviewed-on: https://chromium-review.googlesource.com/c/1361160
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58253}
along with subclasses: Tuple2, Tuple3, FeedbackCell, AccessorPair.
The latter two can be separated out later if desired.
Bug: v8:5402
Change-Id: I4e1a6d2621cc6f96b5da208cff0da7cd5de91672
Reviewed-on: https://chromium-review.googlesource.com/c/1371038
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58251}
Enable --harmony-string-matchall by default.
String.prototype.matchAll behaves similarly to
String.prototype.match, but returns a full regexp
result object for each match in a global or sticky
regexp. This offers a simple way to iterate over
matches when access to e.g. capture groups is
needed.
const string = 'a b c';
const regex = /[ac]/g;
for (const match of string.matchAll(regex)) {
console.log(`${match[0]} at ${match.index}`);
}
// a at 0
// c at 4
More information can be found here:
https://github.com/tc39/proposal-string-matchall
Drive-by: Update debug evaluate side effect
expectations to handle String.p.matchAll and
RegExp.p[@@matchAll]
Bug: v8:6890
Change-Id: Ie3e712af66689936b7d2a15df705b792ccf06bd3
Reviewed-on: https://chromium-review.googlesource.com/c/1377774
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#58250}
Also fail early if we detect that we've previously run out of memory and thus
corrupted the buffer.
Add a unit test for this kind of case.
Bug: chromium:914731
Change-Id: Iaaf3927209bffeab6fe8ba462d9dd9dad8cbbe2f
Reviewed-on: https://chromium-review.googlesource.com/c/1377449
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58248}
Do not set the name property on any function or classes. This is not
required as per spec #sec-__proto__-property-names-in-object-initializers.
Bug: v8:7773
Change-Id: Iade96573690e5b14b60434c37683f782cf9cb2cb
Reviewed-on: https://chromium-review.googlesource.com/c/1375912
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58239}
ProtectedLoad/ProtectedStore opcodes are used in WebAssembly to represent memory
accesses. Since they are not part of the allowed opcodes in OwnedByAddressingOperand
it is not possible to take advantage of addressing modes to encode common patterns
for the pointer input value.
R=jarin@chromium.org
Bug: v8:8508
Change-Id: Ic62bf13fed7b1d86afb112d9aa59cd7073a28e72
Reviewed-on: https://chromium-review.googlesource.com/c/1354458
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58237}
Remove a DCHECK that got triggered in the rare condition that GC kicks in
during CompilationDependencies::Commit, changing the pretenuring decision,
thus leading to deoptimization. To make sure this rare case is properly
handled, add a new FLAG_pretenure_during_compilation and a cctest that
simulates it predictably.
R=jarin@chromium.org,mvstanton@chromium.org
Bug: v8:8520
Change-Id: If83f8a3d4659a694357b3869c931c7d7c164fd1a
Reviewed-on: https://chromium-review.googlesource.com/c/1363143
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58236}
The new ObjectPtr design makes non-inlined helper functions a little
more expensive because "this" is always a pointer where pass-by-value
would be more efficient, which is an issue for functions whose size puts
them right at the threshold of getting inlined or not. String::Get falls
into this category when called from RegExpFlagsFromString. In this case,
we can do even better than restoring inlineability by fine-tuning
the control flow a bit.
This should repair the regression in crbug.com/910573
Bug: chromium:910573
Change-Id: Ie6b68ef01cd978ec502d8d6c1da788c77422dce7
Reviewed-on: https://chromium-review.googlesource.com/c/1369087
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58234}
