This reverts commit b8ac4eb4dc.
Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=1020533
Original change's description:
> [runtime] Correctly handle global stores when global object has proxies
>
> When global object has proxies we should first call hasProperty and
> then call SetProperty if has property returns true. This cl fixes both
> StoreGlobal and StoreLookupGlobal to correctly handle these cases.
>
> Bug: chromium:1018871
> Change-Id: I140514e2119c6bab2125abcdc1b19d46526be5ff
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1889885
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64687}
TBR=mythria@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1018871
Change-Id: I5abbf9275cba17576e1b1e492abd36d6bc1ca1bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893194
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64714}
Previously only Builtins declared TFJ or CPP in builtins-definitions.h
were converted to direct calls in ReduceJSCall. This allows all
builtins with JS linkage to be converted. To facilitate this, it adds
Builtins::HasJSLinkage(id) that returns true for any builtins with
JSTrampolineDescriptor as their call descriptor.
It also ensures that any JS functions installed by the bootstrapper are
also required to have JS linkage to catch early errors.
Change-Id: I2fddca41f9ab1c7c9633aa0ab4847a5c108e2bb2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883549
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64698}
When global object has proxies we should first call hasProperty and
then call SetProperty if has property returns true. This cl fixes both
StoreGlobal and StoreLookupGlobal to correctly handle these cases.
Bug: chromium:1018871
Change-Id: I140514e2119c6bab2125abcdc1b19d46526be5ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1889885
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64687}
JSProxy::HasProperty returns Nothing<bool>() when there is an
exception when executing has trap handler. We should not treat
these cases similar to not found cases.
Bug: chromium:1018871
Change-Id: I5510e707c96576d2dca4c8402e21a89065cc9b90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886919
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64670}
This fixes the streaming decoder to report the correct error position
for repeating code sections (i.e. only one code section per module).
R=clemensb@chromium.org
Change-Id: Ie02d704d74b4e051fa9b00288dd6d1e46e2418a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1890094
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64654}
The test was originally skipped due to slowness. This might have been
fixed by reduced store-store zone allocations (see the linked bug).
Locally, this now runs in less than 20 seconds in full x64 debug mode.
The largest zone is < 100MB:
12089344, "V8.TFAllocateGeneralRegisters"
21954208, "graph-zone"
26181688, "../../src/compiler/verifier.cc:2000"
57895456, "instruction-zone"
98933872, "register-allocation-zone"
Drive-by: Remove tsan SLOW annotation, it's already marked SLOW in the
ALWAYS block.
Bug: v8:9572
Change-Id: Ic3ffd3de732e262f412f1d7a66448ea7228582f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1889872
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64641}
This is a reland of 4a16305b65
The original CL adjust only one part of the stack check, namely the
comparison of the stack pointer against the stack limit in generated code.
There is a second part: Runtime::kStackGuard repeats this check to
distinguish between a stack overflow and an interrupt request.
This second part in runtime must apply the offset just like in generated
code. It is implemented in this reland by the StackCheckOffset operator
and a new StackGuardWithGap runtime function.
Original change's description:
> [compiler] Optionally apply an offset to stack checks
>
> The motivation behind this change is that the frame size of an optimized
> function and its unoptimized version may differ, and deoptimization
> may thus trigger a stack overflow. The solution implemented in this CL
> is to optionally apply an offset to the stack check s.t. the check
> becomes 'sp - offset > limit'. The offset is applied to stack checks at
> function-entry, and is set to the difference between the optimized and
> unoptimized frame size.
>
> A caveat: OSR may not be fully handled by this fix since we've already
> passed the function-entry stack check. A possible solution would be to
> *not* skip creation of function-entry stack checks for inlinees.
>
> This CL: 1. annotates stack check nodes with the stack check kind, where
> kind is one of {function-entry,iteration-body,unknown}. 2. potentially
> allocates a temporary register to store the result of the 'sp - offset'
> in instruction selection (and switches input registers to 'unique'
> mode). 3. Applies the offset in code generation.
>
> Drive-by: Add src/compiler/globals.h for compiler-specific globals.
>
> Bug: v8:9534,chromium:1000887
> Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63701}
Bug: v8:9534, chromium:1000887
Change-Id: I71771c281afd7d57c09aa48ea1b182d01e6dee2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822037
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64634}
The `capture_ix` refers to all captures while `capture_count` only
refers to named captures. Clarified by renaming `capture_count` to
`named_capture_count` and removing the incorrect part of the DCHECK.
The `>= 1` part of the condition must still hold since named captures
can only refer to explicit capture groups, which start at index 1.
Tbr: petermarshall@chromium.org
Bug: chromium:1018592
Change-Id: If8a26f6661ba0483d585f74270b3b4a3853e2ca8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886810
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64629}
1) don't print off-heap TypedArray elements with --mock-arraybuffer-allocator
2) print integer HeapNumbers in safe integer range with max precision:
as 9007199254740991.0 instead of 9.0072e+15
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Bug: v8:4153
Change-Id: Ie79fc08c44374981a840772fde4f414458d31c52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883565
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64609}
Otherwise the expression scope may be in a weird state and DCHECKs for valid
arrow functions in ValidateAndCreateScope willl unnecessarily fire.
Bug: chromium:1018611
Change-Id: I101b8902dce07c29aacba3e7a5e6f86d66505d5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879906
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64591}
This reverts commit d7793c0684.
Reason for revert: This cl *will* cause regexp regressions. We are trying to gauge the real world impact.
Original change's description:
> Revert "[regexp] Clone match info for match indices."
>
> 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}
TBR=jgruber@chromium.org,joshualitt@chromium.org
Bug: v8:9548, chromium:1015749
Change-Id: I151511307e3d8752fdbde4b8247514031b141b08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879587
Reviewed-by: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64587}
When global object has proxies we should first call hasProperty and
then call GetProperty according to spec. This cl fixes both
LoadGlobal and LoadLookupGlobal to correctly handle these cases.
Also fixes tests that didn't expect hasProperty to be called.
Change-Id: I3a45df7ae24be74dd46cf04cafbf8c2d7018b3af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876059
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64580}
This code is triggered by Runtime_ArrayIncludes_Slow. The elements kind
changes from DICTIONARY (with accessor property using
Object.defineProperty) to empty DICTIONARY (by set the length to 0), to
frozen/seal/nonextensible elements. This element kind transition
happened in accessor property by Array.includes.
Bug: v8:9894
Change-Id: I224ceb537ff358a30a6e00414c71d6fe18924bb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876994
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64575}
Both LO_SPACE and NEW_LO_SPACE use the basic page management system of
LargeObjectSpace, but implement different AllocateRaw methods (with
the NEW_LO_SPACE version shadowing the LO_SPACE version).
To clean this up, and allow other future LargeObjectSpace implementations
(in particular, an off-thread variant), refactored the current
LargeObjectSpace into a base class, and make both LargeObjectSpace
(renamed to OldLargeObjectSpace) and NewLargeObjectSpace extend this
class.
Bug: chromium:1011762
Change-Id: I41b45b97f2611611dcfde677213131396df03a5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876824
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64560}
Add VirtualBoundFunction to the serializer which takes care of
processing the result of Function.prototype.bind.
Add cctest and an mjsunit test.
Bug: v8:7790
Change-Id: Ic2b48d356cbe3b576eb22f58215cc886a8994e31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859625
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64548}
Quoting from the spec, the expected behavior for validating unreachable
code is that:
A polymorphic stack cannot underflow, but instead generates
Unknown types as needed.
(https://webassembly.github.io/spec/core/appendix/algorithm.html)
This CL changes the representation of the stack height in the
interpreter's side table builder from unsigned to signed to prevent
underflow, and makes some DCHECKs depend on code reachability.
R=clemensb@chromium.org
Bug: chromium:1017061
Change-Id: I4c999859019d6cefb76c1366ba0e98f199f7a0be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876813
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64546}
Now that segmented code spaces are enabled for WebAssembly, tests that
allocate a large number of modules should no longer flakily run OOM.
R=clemensb@chromium.org
TEST=mjsunit/wasm/asm-wasm-{i32,f64}
BUG=v8:7899
Change-Id: Iab5d2c1b022cc1f6e44f132b14148c86f148cb54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876818
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64545}
This makes sure that functions constructed via {WebAssembly.Function}
can be properly stored in globals of type "funcref". For now it is not
possible to call functions in such globals, but values can be loaded and
stored.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection-with-anyref
BUG=v8:7742
Change-Id: I88ad1b5a57fd50e28723430803c528e674a94321
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876815
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64539}
Original change's description:
> [runtime] Remove extension slots from context objects
>
> Context objects have an extension slot, which contains further
> additional data that depends on the type of the context.
>
> This CL removes the extension slot from contexts that don't need
> them, hence reducing memory.
>
> The following contexts will still have an extension slot: native,
> module, await, block and with contexts. See objects/contexts.h for
> what the slot is used for.
> The following contexts will not have an extension slot anymore (they
> were not used before): script, catch and builtin contexts.
> Eval and function contexts only have the extension slot if they
> contain a sloppy eval.
>
> Bug: v8:9744
> Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
> Commit-Queue: Victor Gomes <victorgomes@google.com>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Auto-Submit: Victor Gomes <victorgomes@google.com>
> Cr-Commit-Position: refs/heads/master@{#64372}
TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
Bug: v8:9744
Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64477}
Currently, RegExpResult builds match indices lazily using data stored
in hidden internal fields on the result object itself. Unfortunately,
if an internal field is deleted, it can cause these hidden fields
to migrate to a dictionary, making indexed lookup unsafe. This CL
forces slow but safe lookup for these fields when lazily building
indices.
Bug: v8:9548, chromium:1013133
Change-Id: Ide87d9ca6a73644ced3de8e35ecac26330d365e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871756
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64474}
Embedded builtins are now unconditionally enabled, which removes the
need to differentiate between enabled/disabled embedded builtins.
This Cl removes the 'embedded_builtins' variant and related
*.status entries.
R=machenbach@chromium.org
Bug: v8:8519
Change-Id: I55d0dd54735b7cc437832af6fa2836fd6c14a317
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864936
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64464}
If a new jump table is created and lazy compilation is enabled, we need
to initialize the new jump table with jumps to the lazy compile table.
R=ahaas@chromium.org
Bug: chromium:1016515
Change-Id: I5749470d4a08af903a6a4da13dbe5454ee6db309
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873687
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64462}
This is a reland of f5611402f7
We had to revert due to branch cut. The A/B experiment wasn't done yet.
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.
>
> Commented out the 'extra' variant since it was crashing. Opened a bug
> regarding that: https://bugs.chromium.org/p/v8/issues/detail?id=9568
>
> Similar to x64's https://chromium-review.googlesource.com/c/v8/v8/+/1607654
>
> Bug: v8:7703
> Change-Id: Ifd46b029bab34524f9f536dcdbd1574f2ddcbf37
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724216
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63019}
Bug: v8:7703
Change-Id: I28726f534dfd17dd695a3ba5653873368e7a44b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872403
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64459}
Parenthesized variable names are valid references for assignment. To make sure
we can properly mark the variable as assigned, we should push parenthesized
variables to the outer expression scope after the parenthesized expression is
guaranteed to not be an arrow head; so that the variable list of the parent is
complete.
Technically we could probably get by with simply pushing a single variable,
since more complex expressions aren't valid parenthesized assignment targets:
(a) = ... and [(a),(b)] = ... are valid, but ([a,b]) = ... isn't.
It doesn't really seem worth it though.
Bug: chromium:1015372
Change-Id: I095c35126742a14d0171537b9795f7258c33ab4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872389
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64455}
This is a reland of c48096d442
Original change's description:
> Reland "[runtime] Remove extension slots from context objects"
>
> This is a reland of c07c02e1c4
>
> Original change's description:
> > [runtime] Remove extension slots from context objects
> >
> > Context objects have an extension slot, which contains further
> > additional data that depends on the type of the context.
> >
> > This CL removes the extension slot from contexts that don't need
> > them, hence reducing memory.
> >
> > The following contexts will still have an extension slot: native,
> > module, await, block and with contexts. See objects/contexts.h for
> > what the slot is used for.
> > The following contexts will not have an extension slot anymore (they
> > were not used before): script, catch and builtin contexts.
> > Eval and function contexts only have the extension slot if they
> > contain a sloppy eval.
> >
> > Bug: v8:9744
> > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
> > Commit-Queue: Victor Gomes <victorgomes@google.com>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Auto-Submit: Victor Gomes <victorgomes@google.com>
> > Cr-Commit-Position: refs/heads/master@{#64372}
>
> TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
>
> Bug: v8:9744
> Change-Id: I0749cc2d8f59940c25841736634a70047116d647
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Auto-Submit: Victor Gomes <victorgomes@google.com>
> Cr-Commit-Position: refs/heads/master@{#64380}
TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
Bug: v8:9744
Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@google.com>
Cr-Commit-Position: refs/heads/master@{#64451}
.. 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}
