This adds a simple test calling:
generate-bytecode-expectations --check-baseline
It's added on one CQ and one CI builder. The infra side specifying the
command line landed here:
https://crrev.com/c/1709454
For the command to succeed on swarming we instruct the isolate server
to archive the executable alongside with all the *.golden files needed
for the --check-baseline command.
Bug: v8:9520
Change-Id: I358ca7a7142c0fdaa7f6960515e524729a481394
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709424
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62844}
1. Sync with
https://github.com/tc39/proposal-unified-intl-numberformat/pull/57
so the formatting of {style: "unit" unit: "percent"} and
the formatting of {style: "percent:"} are treated different that
simplified the algorithm.
2. Store style into bit flags because we need it quickly during format.
3. Add more unit tests and regression test.
Bug: v8:9498
Change-Id: I75ed22fef1feb73ebf624bda70ebe45b80e7bc8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704948
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62834}
Fix CheckBaselineExpectations returning 2 when it can't read its input
file. Since this was originally just in main, convert it to std::exit.
Change-Id: I70ae6fbc6e5e12b748d2ab1cc83b1deb67a8f861
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710659
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62833}
In InterpreterCollectSourcePositions tests always unset
FLAG_stress_lazy_source_positions as the tests cannot work with it due
to assuming that source positions won't be collected immediately after a
normal compile.
Bug: v8:8510
Change-Id: I194ed06c59336f5af3b7b2113a12c1a21dd6bcac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709425
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62832}
Adds a new out param which allows accessing the ScriptOrModule
of a function, which allows an embedder such as Node.js to use
the function's i::Script lifetime.
Refs: https://github.com/nodejs/node-v8/issues/111
Change-Id: I34346d94d76e8f9b8377c97d948673f4b95eb9d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1699698
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62830}
This is a reland of e55e0aa5bd
Original change's description:
> [runtime] Fix protector invalidation
>
> Protectors trigger when special properties are modified or masked. Previously
> we would check whether the property stored on the holder would invalidate the
> protector. Stores to to the receiver rather than the holder, however, so this
> CL changes holder for receiver, and adds additional checks that were missing.
>
> Bug: v8:9466
> Change-Id: I81bc3d73f91381da0d254e9eb79365ae2d25d998
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708468
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62805}
Tbr: leszeks@chromium.org
Bug: v8:9466
Change-Id: I693c73577ca9a35a271f509770cc1c87e5cc4b73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709420
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62829}
This makes sure the language mode of the module is correctly propagated
through the WebAssembly module, so that exported functions are allocated
with the correct language mode. It extends the existing {ModuleOrigin}
enum to consist of three values now.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-985154
BUG=chromium:985154
Change-Id: Id7b566738b1e710cc5001b894022bcd0f2c01bc3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708484
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62826}
Add a new mode to generate-bytecode-expectations to be used in a coming
test that tests that the bytecode expectations generated by
--rebaseline match the current state.
Change-Id: Ic03787cd853f9bf7d9b4412f96a767036c848c61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708477
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62825}
This reverts commit c2ee4a7999.
Reason for revert: webgl_conformance_tests deqp/data/gles2/shaders/conversions.html crashes on Android FYI Release (Nexus 9)
See https://bugs.chromium.org/p/chromium/issues/detail?id=985624
Original change's description:
> Reland "[regexp] Call the regexp interpreter without CEntry overhead"
>
> This is a reland of d4d28b73cb
>
> Original change's description:
> > [regexp] Call the regexp interpreter without CEntry overhead
> >
> > Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
> >
> > This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
> >
> > Bug: v8:8954
> > Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
> > Commit-Queue: Patrick Thier <pthier@google.com>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62753}
>
> Bug: v8:8954
> Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Patrick Thier <pthier@google.com>
> Cr-Commit-Position: refs/heads/master@{#62794}
TBR=jgruber@chromium.org,petermarshall@chromium.org,pthier@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8954, chromium:985624
Change-Id: I5bc2c397a09979f42f28670f80a5366f2a33d80f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709411
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62824}
Fix a cctest/test-bytecode-generator/PrivateMethods mismatch between the
PrivateMethods source string and the snippet in the golden file due to
missing newline at the end of the string. Change C++ raw string back to
a normal string since in this case it makes it harder to see the
problem.
Change-Id: I3bea8873d37fbacac65548be8261f6b04104132f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709413
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62823}
This adds decoding and compilation of the "atomic.fence" operator, which
is intended to preserve the synchronization guarantees of higher-level
languages.
Unlike other atomic operators, it does not target a particular linear
memory. It may occur in modules which declare no memory, or a non-shared
memory, without causing a validation error.
See proposal: https://github.com/WebAssembly/threads/pull/141
See discussion: https://github.com/WebAssembly/threads/issues/140R=clemensh@chromium.org
TEST=cctest/test-run-wasm-atomics/RunWasmXXX_AtomicFence
BUG=v8:9452
Change-Id: Ibf7e46227f7edfe5c81c097cfc15924c59614067
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701856
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62821}
This reverts commit bc33f5aeba.
Reason for revert: Still failing (OOM on win32): https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/22210
Original change's description:
> Reland "[arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of 31cd5d83d3
>
> Original change's description:
> > [arraybuffer] Rearchitect backing store ownership
> >
> > This CL completely rearchitects the ownership of array buffer backing stores,
> > consolidating ownership into a {BackingStore} C++ object that is tracked
> > throughout V8 using unique_ptr and shared_ptr where appropriate.
> >
> > Overall, lifetime management is simpler and more explicit. The numerous
> > ways that array buffers were initialized have been streamlined to one
> > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > and the construction and destruction of the BackingStore object itself
> > handles the underlying page or embedder-allocated memory.
> >
> > The embedder API remains unchanged for now. We use the
> > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > keep the backing store alive properly, even in the case of aliases
> > from live heap objects. Thus the embedder has a lower chance of making
> > a mistake. Long-term, we should move the embedder to a model where they
> > manage backing stores using shared_ptr to an opaque backing store object.
> >
> > R=mlippautz@chromium.org
> > BUG=v8:9380,v8:9221
> >
> > Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
> > Commit-Queue: Ben Titzer <titzer@chromium.org>
> > Reviewed-by: Ben Titzer <titzer@chromium.org>
> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > Reviewed-by: Yang Guo <yangguo@chromium.org>
> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62572}
>
> Bug: v8:9380, v8:9221
> Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62809}
TBR=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,titzer@chromium.org,gdeepti@chromium.org,mlippautz@chromium.org
Change-Id: Iea755df9aaa1e95d284135bd0a6681b1340b6832
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9380, v8:9221
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708487
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62811}
Previously both tracing implementations would be run side-by-side when
perfetto was enabled with the V8_USE_PERFETTO build flag. This CL
makes them run separately.
Both implementations now use the trace file provided by the user in D8
or the default v8_trace.json.
Add tests for perfetto events (which must be tested differently
due to the proto output format).
Drive-by fix: Fix pass-by non-const ref in GetJSONStrings.
Remove the TraceEvent struct for testing; we can just store a copy of
the protobuf directly.
Bug: v8:8339
Change-Id: Id50003e0f96e44b99a63a26693da6bdaca989504
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1702619
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62810}
This is a reland of 31cd5d83d3
Original change's description:
> [arraybuffer] Rearchitect backing store ownership
>
> This CL completely rearchitects the ownership of array buffer backing stores,
> consolidating ownership into a {BackingStore} C++ object that is tracked
> throughout V8 using unique_ptr and shared_ptr where appropriate.
>
> Overall, lifetime management is simpler and more explicit. The numerous
> ways that array buffers were initialized have been streamlined to one
> Attach() method on JSArrayBuffer. The array buffer tracker in the
> GC implementation now manages std::shared_ptr<BackingStore> pointers,
> and the construction and destruction of the BackingStore object itself
> handles the underlying page or embedder-allocated memory.
>
> The embedder API remains unchanged for now. We use the
> v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> keep the backing store alive properly, even in the case of aliases
> from live heap objects. Thus the embedder has a lower chance of making
> a mistake. Long-term, we should move the embedder to a model where they
> manage backing stores using shared_ptr to an opaque backing store object.
>
> R=mlippautz@chromium.org
> BUG=v8:9380,v8:9221
>
> Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62572}
Bug: v8:9380, v8:9221
Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62809}
This reverts commit e55e0aa5bd.
Reason for revert: speculative revert for tsan breakage
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8907588363297935904/+/steps/Check__flakes_/0/logs/regress-437713/0
Original change's description:
> [runtime] Fix protector invalidation
>
> Protectors trigger when special properties are modified or masked. Previously
> we would check whether the property stored on the holder would invalidate the
> protector. Stores to to the receiver rather than the holder, however, so this
> CL changes holder for receiver, and adds additional checks that were missing.
>
> Bug: v8:9466
> Change-Id: I81bc3d73f91381da0d254e9eb79365ae2d25d998
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708468
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62805}
TBR=leszeks@chromium.org,verwaest@chromium.org
Change-Id: Id8fc36525b7c5631589a67073ad1fd5815ea2775
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9466
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708482
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62807}
Protectors trigger when special properties are modified or masked. Previously
we would check whether the property stored on the holder would invalidate the
protector. Stores to to the receiver rather than the holder, however, so this
CL changes holder for receiver, and adds additional checks that were missing.
Bug: v8:9466
Change-Id: I81bc3d73f91381da0d254e9eb79365ae2d25d998
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708468
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62805}
With a write barrier, stores with negative offsets would allocate a temporary
register to hold the offset when the `str` instruction is able to encode it.
For instance, when writing the object map:
```
;; This could be 'str x2, [x5, #-1]'
movn x4, #0x0
str x2, [x5, x4]
and x16, x5, #0xfffffffffffc0000
ldr x16, [x16, #8]
tbnz w16, #2, #+0xba8 ; Jump out-of-line
```
The reason behind this is that the out-of-line code uses an 'add' instruction on
the offset to compute the field address, putting pressure on the instruction
selector to make sure the immediate fits in both 'str' and 'add'.
But, this is not necessary since the macro-assembler is able to turn the 'add'
into a 'sub' or use a temporary register if needed.
Change-Id: I8838e4b81a0c0c1f90aa3d67861a9da1a6dfed06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708471
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#62803}
This test fails in --stress-opt mode because backing stores of
memories/arraybuffers that are postMessage()'d leak in d8. In normal
mode, only ~16 memories are allocated, which is not enough to OOM,
but in stress mode, it can be 5x that number. Should be fixed
by upcoming ownership changes.
BUG=v8:9380
R=clemensh@chromium.org
Change-Id: Iecec07d15339cf43b23f128f13d570dfe3b32130
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708475
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62802}
If we flush the bytecode from a SFI we might recompile a JSFunction while the function
still has its old feedback vector. This should usually be fine since the new and old
feedback vectors have the same layout, however some bugs in the parser mean that it's
possible for eagerly and lazily compiled eval functions to have different bytecode and
so potentially different feedback vector layouts.
For now reset the feedback vector if it doesn't have the same size when we compile the
JSFunction, and recreate a new one of the correct layout. This will be replaced with a
CHECK once the parser bugs are fixed.
BUG=chromium:984344,v8:9511
Change-Id: Ib8976f2541516f7a07e4d4ab7dc3c750dfe9b5d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708474
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62800}
When the main thread contributes to an item parallel job and runs
an item parallel task, it currently emits a background GC trace event.
That is confusing and may lead to incorrect accounting of main thread
GC time. This patch fixes it by introducing a 'Runner' parameter
to ItemParalllelJob::Task::RunInParallel and emitting a foreground
GC event if the runner is the main thread.
Bug: v8:9508
Change-Id: I755751bfe9eef427666d5f16fb50aa6093059e80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706485
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62798}
With recent spec changes, table.copy of length 0 does not trap anymore,
and we copy backwards whenever src < dst.
R=binji@chromium.org
Change-Id: I48e2b65083565631abc41bf4fdf4971f80fdf440
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706471
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62797}
This is a reland of d4d28b73cb
Original change's description:
> [regexp] Call the regexp interpreter without CEntry overhead
>
> Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
>
> This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
>
> Bug: v8:8954
> Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
> Commit-Queue: Patrick Thier <pthier@google.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62753}
Bug: v8:8954
Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@google.com>
Cr-Commit-Position: refs/heads/master@{#62794}
Adding two small builtins pushed this test over the OOM threshold,
so we disable it for now.
Bug: v8:9488
Change-Id: I6c0696c260cd8ef9e6ee59caec4848aab439fdf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706049
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62783}
If multiple isolates are involved, we can run OOM when creating many
wasm memories, because we only trigger GC in one isolate at a time.
TBR=titzer@chromium.org
No-Try: true
Change-Id: I037b5a13c670c5da2abe54b5045df94637c94f72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706484
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62782}
By having the proposal tests now as part of the wasm-spec-tests, we do
not need them here anymore.
R=clemensh@chromium.orgCC=binji@chromium.org
Change-Id: I2530a4d2e2e8caa6fe8ef4d7e7b8b6da550a5134
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706475
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62778}
With this CL we add proposal tests to the wasm-spec-tests. For this I
extended the update-wasm-spec-tests.sh script. Additionally to
generating the spec tests it does the following:
For each proposal it identifies those tests that are different to the
spec tests, and then copies those tests also to the wasm-spec-tests
directory.
Additionally I adjusted the test runner of the wasm spec test to
run the proposal tests with the correct flags.
CC=binji@chromium.orgR=clemensh@chromium.org
Bug: v8:7581
Change-Id: Idb7aa3c0a468ddb65b2ef3421def836561579cd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706470
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62777}
This CL adds more stress-tests for both shared array buffers and
WebAssembly memories. Because of an existing memory leak that will
be fixed in upcoming CLs, some new tests are disabled.
R=mstarzinger@chromium.org
BUG=v8:9380
Change-Id: I2662e3d0a764a032a0c267b2d99e3ccd1a4951d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697252
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62770}
es6/classes.js is large and causes timeouts and OOM on some of the
configurations.
Bug: v8:9246
Change-Id: Iaabfc39dd8f9554e16f67d66ce64acd3dd56b9ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704103
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62758}
This reverts commit d4d28b73cb.
Reason for revert: breaks TSAN bot:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20concurrent%20marking/9526
Original change's description:
> [regexp] Call the regexp interpreter without CEntry overhead
>
> Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
>
> This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
>
> Bug: v8:8954
> Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
> Commit-Queue: Patrick Thier <pthier@google.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62753}
TBR=jgruber@chromium.org,petermarshall@chromium.org,pthier@google.com
Change-Id: I3257220c4359a3b801dd80e0eff6c4534d8badee
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8954
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706050
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62757}
This adds a simple counter to Turbofan that's incremented throughout the compilation, hopefully
frequently enough so we can use it to detect divergence and performance bugs.
In addition, we assert that this counter never gets too high. That's the equivalent of a simple
timeout, just more deterministic. The limitations on Turbofan input size should guarantee that
we never exceed this limit. Since we probably do exceed it rarely, this check is only a DCHECK and
intended to detect performance and divergence issues, but not supposed to be performed in release
builds.
In addition, this CL adds UMA stats to observe the real world distribution of the tick measurement.
Bug: v8:9444
Change-Id: I182dac6ecac64715e3f5885ff5c7c17549351cd0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695475
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62754}
Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
Bug: v8:8954
Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
Commit-Queue: Patrick Thier <pthier@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62753}
Change-Id: I99fe89a679e6a628bd6fa7600f756d9a35450243
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695203
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62751}
pcmpgtq was added in https://crrev.com/c/1684362 but not to the
disasembler.
Bug: v8:8460
Change-Id: Id30f9ece015713e8597f5e218dc066ab75ccec96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1703766
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62750}
Add CPU trace mark extension for adding a magic instruction like 'cpuid'
to the code stream when perform trace collection.
This feature can be enabled by --expose-cputracemark-as=THE_NAME_YOU_SPECIFIED option.
Change-Id: I33e94793cddf4956dbb3ddddf2f599420aa4a945
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1699749
Commit-Queue: Tianyou Li <tianyou.li@intel.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62749}
This CL adds the support for Base64 VLQ decoding, which is the base of
parsing source map files (Version 3). With this support, the mappings of
C/C++ source code and WASM bytecode could be built in V8 engine. The
newly-added function is called VLQBase64Decode, which accepts two
character to be decoded. Upon its return, the position is updated with
the next start position. The unittest of this support is also added in
this CL.
argument: the Base64-encoded VLQ string and the position of first
Change-Id: If0f32972ecd7488844478a7b93a0f10cc38b6a5d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657421
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Zhiguo Zhou <zhiguo.zhou@intel.com>
Cr-Commit-Position: refs/heads/master@{#62748}
