.. similar to how it is applied in the interpreter. We reserve a stack
slot for the backtrack count, increment it on each backtrack, and fail
if the limit is hit.
Bug: v8:9695
Change-Id: I835888c612d6c8bfa2f34e73ab8c8241dcabc6ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864938
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64426}
V8 uses a backtracking regexp engine, which has the caveat that some
regexp patterns can have exponential runtime behavior when excessive
backtracking is involved.
Especially when regexp patterns are user-controlled, it would be useful
to be able to set an upper limit for a single regexp execution. This CL
takes an initial step in that direction by adding a backtracking limit
(intended to approximate execution time):
- The limit is stored in the JSRegExp's data array.
- A limit can currently only be set through the %NewRegExpWithLimit
runtime function.
- The limit is applied during interpreter execution. When exceeded, the
interpreter stops execution and returns FAILURE (even if continued
execution would at some later point have resulted in SUCCESS).
In follow-up CLs, this mechanism will be extended to work in jitted
regexp code, and exposed through the V8 API.
Bug: v8:9695
Change-Id: Iadb5c100052f4a63b26f1ec49cf97c6713a66b9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864934
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64417}
This reverts commit dfd9ceb984.
Reason for revert: Regressions https://chromeperf.appspot.com/group_report?rev=64356https://crbug.com/1015749
Original change's description:
> [regexp] Clone match info for match indices.
>
> The current behavior for generating match indices simply stashes a
> pointer to the match info and then constructs the indices lazily.
> However, it turns out the match info object used to create the result
> object is the regexp_last_match_info living on native context, and thus
> it can change between the creation of the result object and the generation
> of indices. This cl clones the match info which will be safer.
>
> Bug: v8:9548
> Change-Id: Ia6f26f88fbc22fd09671bf4c579d39a1510b552d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864585
> Commit-Queue: Joshua Litt <joshualitt@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64356}
TBR=jgruber@chromium.org,joshualitt@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9548, chromium:1015749
Change-Id: I9c30b8fb459cf2aa89d920bf061614441250844d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870236
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64407}
When using promise hooks we can actually end up in capturing stack trace
with an async generator on the stack whose queue is empty, and we need
to gracefully handle that case as well.
Fixed: chromium:1015945
Change-Id: Ia459e7444b373ecab01ca6900a781fd8b4021d1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870230
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64403}
At certain points in time we learn that we have to drop certain errors in the
ExpressionScope. If an AccumulationScope appears between where we learn about
the error and where we drop the error, we previously stopped accumulating,
assuming that we're already going to fail anyway. Since we might drop the
earlier error later; we can't early on this. Instead the accumulator should
simply keep on accumulating, keeping the earlier error alive across
accumulation.
Bug: chromium:1015567
Change-Id: I4d70643d02233fe82582b568a0a946eacf883880
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869198
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64384}
This reverts commit ca1259fcac.
Reason for revert: Branch was cut and we don't want the flag flip shipping.
Original change's description:
> [ptr-compr][arm64] Temporarily enable pointer compression on arm64
>
> ... and make sure that the arm64 ptr-compr bots proceed testing V8 without
> pointer compression in order to keep testing the other config.
>
> Bug: v8:7703
> Change-Id: I0017345273d5328d95a338064dd80b44974c1c53
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1844780
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64132}
TBR=machenbach@chromium.org,ishell@chromium.org,tmrts@chromium.org,solanes@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7703
Change-Id: I67c244e583893bb1062dbaa610c9c470fbfb9e40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1868610
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64374}
DefineClass uses the ClassBoilerplate to directly construct the
property descriptor array or dictionary for defining the class
constructor and prototype, skipping use of the LookupIterator and the
encapsulated protector update logic. This patch adds manual calls
to UpdateProtector(), which is in particular relevant for the
isConcatSpreadable protector.
Bug: v8:9837
Change-Id: I7b9d8105d41f5f0f826ca2ce35d6bf3d1aeee6e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863644
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64368}
Split up the test so each test runs in a fresh Isolate with pristine
protector state.
Note that testArrayConcatES5 was not split out because it is a duplicate
of mjsunit/array-concat.js, and testConcatRevokedProxy has already been
split out as mjsunit/es6/array-concat-revocable-revoked-proxy-[12].js.
Bug: v8:9837
Change-Id: I8f744b0263c82f1dae61a55032124d9129f8e6f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864007
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64366}
The current behavior for generating match indices simply stashes a
pointer to the match info and then constructs the indices lazily.
However, it turns out the match info object used to create the result
object is the regexp_last_match_info living on native context, and thus
it can change between the creation of the result object and the generation
of indices. This cl clones the match info which will be safer.
Bug: v8:9548
Change-Id: Ia6f26f88fbc22fd09671bf4c579d39a1510b552d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864585
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64356}
The serializer doesn't correctly propagate environment information
from try blocks into their catch handlers, and this impedes
optimizations that fire when we compile concurrently.
function bar(x) {
try {
boom(); // throws
} catch(_) {
return x.a;
}
}
function foo() { return bar({a: 42}); }
When foo is optimized, we can normally return the constant 42
directly. This CL makes that work for concurrent inlining.
Bug: v8:7790
Change-Id: Id1c5fd06d51ec6fe69ab10fbd65afd6fa7e76820
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863193
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64352}
This extends existing table support to be able to store 'exnref' in
addition to 'anyref' types. Tools can use this to maintain data
structures for exception packages.
R=ahaas@chromium.org
TEST=mjsunit/wasm/exceptions-anyref
BUG=v8:8091
Change-Id: Iccbcfdc328db81a366921bcdd98c2256f66e7fc8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781046
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64323}
With the recent removal of the --wasm-shared-code flag, it became
effectively impossible to turn off this flag. Hence its functionality
became mandatory and the ability to turn off sharing of {WasmEngine}
process-wide has to be removed as well.
R=clemensb@chromium.org
Change-Id: I7c25e909e49134a226d6a9fe9c42f0ecd9d02a69
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864935
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64322}
It turns out that because we are *subtracting* from fp, we need to
*subtract less* to get a higher address. Who knew.
R=jkummerow@chromium.org
Bug: v8:9830, chromium:1014798
Change-Id: I5b9782dd0be27f4c3efbd306ec6c3450b249cb55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864933
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64321}
Updates CSA::TryToIntptr to handle array indices that are less than
INT_MAX which allows to handle string keys in the ICs.
Updates ICs to go monomorphic for string keys that are array indices.
Updates Turbofan to handle array indices when lowering element access.
Change-Id: Ibdde20130e075d0d645ab4a8266a968335eaad84
Bug: v8:9449
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813018
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64320}
This prevents the branch table iterator's has_next() method to trigger a
DCHECK when the decoder fails before the end of table decoding.
R=clemensb@chromium.org
Change-Id: I2258886501b77cd4c8fe98bc8a4ed0b66fb23066
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864931
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64312}
This fixes a bug where coverage for the inline script
<script>function foo() {}<script>
started to get deterministically reported as covered
after crrev.com/c/1771776, while before it, we most of
the time reported it as uncovered (depending on heap
order of SFIs). The correct result is to report `foo`
as uncovered as it is never called.
The problem arose from the fact that v8:9212 needed to
handle extra-wrappers around scripts correctly. Those
wrappers have the same source range as the wrapped
script and a call count of zero even if the wrapped
script is executed. To filter them out, we previously
determined nesting for identical source ranges by
ascending call count. However, in the script case above,
the script has call count one, while `foo` (which has
the same source range) has call count zero. In this
case, nesting is decreasing order of call counts.
This CL is a minimal change that sorts SFIs which are
top-level to the front, only then considers call counts
in descending order. This preserves the behavior that
node's extra wrappers are sorted to the front (and
then filtered out by existing logic), but also ensures
that for the example above, we report the script's
coverage before the coverage for `foo`.
Bug: v8:9857, v9:9212
Change-Id: Id224b0d8f12028b1f586ee5039e126bb5b8d8d36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863197
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64307}
Named capture properties on the groups object should be ordered by the
capture index (and not alpha-sorted). This was accidentally broken in
https://crrev.com/c/1687413.
Bug: v8:9822,v8:9423
Change-Id: Iac6f866f077a1b7ce557ba47e8ba5d7e7014b3ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864829
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64306}
AsmJs does not support SharedArrayBuffers. This CL adds a check in
instantiation and reports a proper error.
Bug: chromium:1013920
Change-Id: Id7159f23ddcc2bde139c4c97bdb67ef3dc7f0e22
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862563
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64291}
Fix uses of cached descriptors arrays used in loops that map-check
to ensure validity of the cache to also reload the descriptor in
case there are missed in-place representation updates.
As a drive-by, introduce inner HandleScopes for these loops.
Bug: chromium:1012301
Change-Id: I17273caf629a181b846d3c09777b5c08fd8cbb0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859621
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64287}
With exception handling enabled new call paths open up, which will
perform environment merging while a "call" or "call_indirect" is
currently being emitted. This will lead to double-use of the buffer
returned by calls to {Buffer} or {Realloc}. In general we should
transition away from this optimization to safer constructs such as
{base::SmallVector} to avoid such bugs.
R=clemensb@chromium.org
TEST=mjsunit/regress/regress-9832
BUG=v8:9832
Change-Id: I4c862ac1bc7dc34ad62279c82f6414153e8cbddb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1856006
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64271}
Increase the embedded vector size to 91 as that is the max size needed to print
a s128 as a 32x4.
- max value of uint32_t has 10 digits in decimal, 1 for a potential sign,
3 spaces in between 4 of them -> 3 + 4 * 11 = 47
- max value of uint32_t has 8 digits in hex, 3 spaces in between -> 3 + 4 * 8 = 35
- the prefix "v128:" -> 5
- " / " to separate the decimal and hex representation -> 3
- null byte
47 + 35 + 5 + 3 + 1 = 91
Bug: v8:9754
Change-Id: I153c30738fa8862b44fb5103cbe62ea0bcea9718
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1814885
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64256}
This patch implements https://github.com/tc39/proposal-class-fields/pull/269
and makes sure we always throw TypeError when there is invalid private
name access in computed property keys.
Before this patch, private name variables of private fields and methods
are initialized together with computed property keys in the order they
are declared. Accessing undefined private names in the computed property
keys thus fail silently.
After this patch, we initialize the private name variables of private
fields before we initialize the computed property keys, so that invalid
access to private fields in the computed keys can be checked in the IC.
We now also initialize the brand early, so that invalid access to private
methods or accessors in the computed keys throw TypeError during brand
checks - and since these accesses are guarded by brand checks, we can
create the private methods and accessors after the class is
defined, and merge the home object setting with the creation
of the closures.
Bug: v8:8330, v8:9611
Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64225}
While removing dead code, v8 currently removes jump targets, but leaves
suspend points, resulting in bytecode analysis issues. This cl simply
removes the suspend point if the remainder of the block is dead.
Bug: v8:9825
Change-Id: Ib147ca01cf64c695c0316017852d61f52fd10cf4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1849197
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64223}
This patch refactors the declaration and allocation of the class variable, and
implements static private methods:
- The class variable is declared in the class scope with an explicit
reference through class_scope->class_variable(). Anonymous classes
whose class variable may be accessed transitively through static
private method access use the dot string as the class name. Whether
the class variable is allocated depending on whether it is used.
Other references of the class variable in the ClassLiteral AST node
and the ClassInfo structure are removed in favor of the reference
through the class scope.
- Previously the class variable was always (stack- or context-)
allocated if the class is named. Now if the class variable is only
referenced by name, it's stack allocated. If it's used transitively
by access to static private methods, or may be used through eval,
it's context allocated. Therefore we now use 1 less context slots
in the class context if it's a named class without anyone referencing
it by name in inner scopes.
- Explicit access to static private methods or potential access to
static private methods through eval results in forced context
allocation of the class variables. In those cases, we save its index
in context locals in the ScopeInfo and deserialize it later, so that
we can check that the receiver of static private methods is the class
constructor at run time. This flag is recorded as
HasSavedClassVariableIndexField in the scope info.
- Classes that need the class variable to be saved due to
access to static private methods now save a
ShouldSaveClassVariableIndexField in the preparse data so that the
bits on the variables can be updated during a reparse. In the case
of anonymous classes that need the class variables to be saved,
we also re-declare the class variable after the reparse since
the inner functions are skipped and we need to rely on the preparse
data flags to remember declaring it.
Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit
Bug: v8:8330
Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64219}
CheckedInt32ToTaggedSigned -> ChangeTaggedSignedToCompressedSigned was
being simplified to CheckedInt32ToCompressedSigned. However, sometimes
the effect chain is not propagated correctly. Since we have plans to
remove the Compressed MachineRepresentation, we can remove this
optimization now.
Bug: v8:7703, chromium:1011980
Change-Id: I9198c73666848f89db96928259af68400d442229
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847363
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64178}
This brings our constants back in line with the changed spec text. We
already use kExprTableGet and kExprTableSet, but for locals and globals
we still use the old wording.
This renaming is mostly mechanical.
PS1 was created using:
ag -l 'kExpr(Get|Set)Global' src test | \
xargs -L1 sed -E 's/kExpr(Get|Set)Global\b/kExprGlobal\1/g' -i
PS2 contains manual fixes.
R=mstarzinger@chromium.org
Bug: v8:9810
Change-Id: I064a6448cd95bc24d31a5931b5b4ef2464ea88b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847355
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64163}
This brings our constants back in line with the changed spec text. We
already use kExprTableGet and kExprTableSet, but for locals and globals
we still use the old wording.
This renaming is mostly mechanical.
PS1 was created using:
ag -l 'kExpr(Get|Set|Tee)Local' src test | \
xargs -L1 sed -E 's/kExpr(Get|Set|Tee)Local\b/kExprLocal\1/g' -i
PS2 contains manual fixes.
R=mstarzinger@chromium.org
Bug: v8:9810
Change-Id: I1617f1b2a100685a3bf56218e76845a9481959c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847354
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64161}
The particular combination of (1) having callee-saved registers in
the stub per the C++ calling convention, (2) passing arguments to
the callee on the stack, and (3) that callee throwing an exception,
caused the saved registers to be restored to bogus values.
To fix this, the stack unwinder needs to compute the stub's frame
size correctly (i.e. without stack parameters).
Bug: chromium:1007608
Change-Id: Iadd99f10764f49f9e3c620c05723e09172c73cf7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847352
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64160}
Empty slow element dictionary had the sticky bit set. This bit was
used to indicate that the dictionary cannot go to the fast mode either
because the dictionary had elements with attributed or elements at large
indices. There is no reason for the empty dictionary to have this bit set.
This causes bugs in some corner cases.
Bug: chromium:1003732
Change-Id: Ib29e1cda784869b9deb9361d8e6b5539f7154a38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1833686
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64158}
The test creates 10000 modules, which runs in less then one second in
release builds, but can take much longer with stress flags and on
special bots.
It timed out on the tsan isolates bot in a variant passing
--stress-wasm-code-gc.
Since the test should only verify that we support more than 1000
modules in a single isolate, we do not need to run it in that variant.
Thus just skip it.
R=fgm@chromium.org
Bug: v8:9814
Change-Id: Ie3a4f62a053b1f7cff2c2206f39ddd71a533ae3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1845229
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64153}
... and make sure that the arm64 ptr-compr bots proceed testing V8 without
pointer compression in order to keep testing the other config.
Bug: v8:7703
Change-Id: I0017345273d5328d95a338064dd80b44974c1c53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1844780
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64132}
This deletes unresolved VariableProxy objects created for labels in the
preparser which prevents shadowed variables in enclosing scopes from
being context-allocated.
Previously this was only done in the full parser, which leads to
bytecode mismatches with lazy source positions.
Bug: chromium:1009728, v8:8510
Change-Id: If2d0c345346116a7f5aacbcd0cf3638e9f7e04cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1836258
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64104}
Fix corner case where we would try to read a property when having a
pending or scheduled exception.
Re-add tests.
Bug: chromium:1006640
Change-Id: I2fc84ee0f6145db2d200a8b9abf57fdc4b12a5a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1835531
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64083}
This is a reland of cfb60d430b
Original change's description:
> [regexp] Eagerly tier-up for very long strings
>
> For very long subject strings, the regexp interpreter is currently much slower
> than the native machine code execution. This CL implements eager tier-up to the
> compiler to avoid the performance penalty for subject strings of length greater
> than 1000.
>
> Change-Id: I244ccbd60255e0f3bedc493b1cc3d25cdd42133e
> Bug: v8:9566
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1829273
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Ana Pesko <anapesko@google.com>
> Cr-Commit-Position: refs/heads/master@{#64046}
Bug: v8:9566
Change-Id: I81a10728c64ce3b35258c31eb8178e458d3de205
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1832167
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Ana Pesko <anapesko@google.com>
Cr-Commit-Position: refs/heads/master@{#64063}
Since slow handler was previously not a Smi. The DCHECK assumed any
Smi Handler on this path should be a proxy handler. Now it Checks for
both, and should continue if the current handler is a slow handler.
Bug: chromium:1008632
Change-Id: I079960894d7320d8d658d0990e8c32db51703206
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1828480
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Suraj Sharma <surshar@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#64052}
This reverts commit cfb60d430b.
Reason for revert: Several bots timing out, e.g.
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24717
Original change's description:
> [regexp] Eagerly tier-up for very long strings
>
> For very long subject strings, the regexp interpreter is currently much slower
> than the native machine code execution. This CL implements eager tier-up to the
> compiler to avoid the performance penalty for subject strings of length greater
> than 1000.
>
> Change-Id: I244ccbd60255e0f3bedc493b1cc3d25cdd42133e
> Bug: v8:9566
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1829273
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Ana Pesko <anapesko@google.com>
> Cr-Commit-Position: refs/heads/master@{#64046}
TBR=yangguo@chromium.org,petermarshall@chromium.org,anapesko@google.com
TBR=yangguo@chromium.org
Change-Id: Id8dd362617988c8c5efa87ae157ee91c96cb1fdf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1832163
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Ana Pesko <anapesko@google.com>
Cr-Commit-Position: refs/heads/master@{#64047}
For very long subject strings, the regexp interpreter is currently much slower
than the native machine code execution. This CL implements eager tier-up to the
compiler to avoid the performance penalty for subject strings of length greater
than 1000.
Change-Id: I244ccbd60255e0f3bedc493b1cc3d25cdd42133e
Bug: v8:9566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1829273
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Ana Pesko <anapesko@google.com>
Cr-Commit-Position: refs/heads/master@{#64046}
