DecideToPretenureDuringCompilation expects a particular number of
allocation sites. So enable lazy feedback allocation always in the test.
It is possible to make the test work for --no-lazy-feedback-allocation
too, but the test already runs in a controlled environment by setting
various flags so it is OK to enable lazy feeedback allocation to keep
test simple
Bug: v8:10219
Change-Id: I8b979b6df7e7cc27299704823ab691f96abe5431
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2521591
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71000}
This reverts commit c3b2b64be4.
Reason for revert: Scheduled revert.
The flag flip is in 88.0.4315.0. Group report links:
https://chromeperf.appspot.com/group_report?rev=70949https://chromeperf.appspot.com/group_report?rev=823663
Original change's description:
> [nci] Enable --turbo-nci behind --future to gather perf data
>
> .. to be reverted in a day or two.
>
> Bug: v8:8888
> Change-Id: Iee156da614b50c351ca9a07cc497177c92de865d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512907
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Lutz Vahl <vahl@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70949}
TBR=machenbach@chromium.org,jgruber@chromium.org,vahl@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8888,v8:11087
Change-Id: I57411474d885dd69613a85f5fa3a801a573fcd08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2517690
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70982}
.. to be reverted in a day or two.
Bug: v8:8888
Change-Id: Iee156da614b50c351ca9a07cc497177c92de865d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512907
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Lutz Vahl <vahl@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70949}
The flaky failure is three years old, let's see how it behaves today.
Bug: v8:5920
Change-Id: Idaa71d274f937e3c6997b49e0acfe7cc88e64956
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484571
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70600}
test-heap-profiler/AllocationSitesAreVisible was disabled unnecessarily
for quite some time. With a minor fix, it's possible to validate that
an AllocationSite can be seen through the heap profiler interface.
Change-Id: I0ac6c218da12ab268bd08c65926149f5c00e5b06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474778
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70537}
Due to a bug on AIX, some of the glibc FP functions do not
preserve the sign bit when a negative input is passed by
value and the output is rounded to 0:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97086
This CL forces the use of "-0.0" in such cases.
Change-Id: If9935596e32e97720f3cb22f27975267ac1124d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2468618
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#70512}
This change adds test functions to check that the Torque-generated
verifiers can catch a few basic kinds of errors and crash the process.
Bug: v8:7793
Change-Id: If0d2b1e8834c3e602c2677253ad3a920566414bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469039
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70506}
This is a reland of 3593ee832c
The MSAN doesn't seem to be considering initializing stores via inline
assembly as such (in a new cctest helper GetStackPointer()), so this
reland attempt fixes the issue and ensures that the MSAN bot is happy.
Original change's description:
> Reland "[csa] Fix semantics of PopAndReturn"
>
> This is a reland of 5e5eaf7954
>
> This CL fixes the "function returns address of local variable" issue
> which GCC was complaining about by using inline assembly instead of
> address of a local for getting stack pointer approximation.
>
> Original change's description:
> > [csa] Fix semantics of PopAndReturn
> >
> > This CL prohibits using PopAndReturn from the builtins that
> > have calling convention with arguments on the stack.
> >
> > This CL also updates the PopAndReturn tests so that even off-by-one
> > errors in the number of poped arguments are caught which was not the
> > case before.
> >
> > Motivation:
> >
> > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
> > dropping ALL JS arguments that are currently located on the stack.
> > Disallowing PopAndReturn in builtins with stack arguments simplifies
> > semantics of this instruction because in case of presence of declared
> > stack parameters it's impossible to distinguish the following cases:
> > 1) stack parameter is included in JS arguments (and therefore it will
> > be dropped as a part of 'pop' number of arguments),
> > 2) stack parameter is NOT included in JS arguments (and therefore it
> > should be dropped in ADDITION to the 'pop' number of arguments).
> >
> > This issue wasn't noticed before because builtins with stack parameters
> > relied on adapter frames machinery to ensure that the expected
> > parameters are present on the stack, but on the same time the adapter
> > frame tearing down code was effectively recovering the stack pointer
> > potentially broken by the CSA builtin.
> >
> > Once we get rid of the arguments adapter frames keeping stack pointer
> > in a valid state becomes crucial.
> >
> > Bug: v8:5269, v8:10201
> > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
> > Commit-Queue: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70454}
>
> Tbr: tebbi@chromium.org
> Bug: v8:5269
> Bug: v8:10201
> Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70483}
Tbr: tebbi@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng
Bug: v8:5269
Bug: v8:10201
Change-Id: Ib09af2d1260bb42ac26aabface14e6b83b3efec4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467847
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70492}
As a drive-by, enable tests that are safe for Arm32/64 to run.
Bug: v8:10833
Change-Id: I8fed5651399852f9ce8ba7d5acdb7ed27ca28e89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467841
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70491}
This reverts commit 3593ee832c.
Reason for revert: MSan issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/34798
Original change's description:
> Reland "[csa] Fix semantics of PopAndReturn"
>
> This is a reland of 5e5eaf7954
>
> This CL fixes the "function returns address of local variable" issue
> which GCC was complaining about by using inline assembly instead of
> address of a local for getting stack pointer approximation.
>
> Original change's description:
> > [csa] Fix semantics of PopAndReturn
> >
> > This CL prohibits using PopAndReturn from the builtins that
> > have calling convention with arguments on the stack.
> >
> > This CL also updates the PopAndReturn tests so that even off-by-one
> > errors in the number of poped arguments are caught which was not the
> > case before.
> >
> > Motivation:
> >
> > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
> > dropping ALL JS arguments that are currently located on the stack.
> > Disallowing PopAndReturn in builtins with stack arguments simplifies
> > semantics of this instruction because in case of presence of declared
> > stack parameters it's impossible to distinguish the following cases:
> > 1) stack parameter is included in JS arguments (and therefore it will
> > be dropped as a part of 'pop' number of arguments),
> > 2) stack parameter is NOT included in JS arguments (and therefore it
> > should be dropped in ADDITION to the 'pop' number of arguments).
> >
> > This issue wasn't noticed before because builtins with stack parameters
> > relied on adapter frames machinery to ensure that the expected
> > parameters are present on the stack, but on the same time the adapter
> > frame tearing down code was effectively recovering the stack pointer
> > potentially broken by the CSA builtin.
> >
> > Once we get rid of the arguments adapter frames keeping stack pointer
> > in a valid state becomes crucial.
> >
> > Bug: v8:5269, v8:10201
> > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
> > Commit-Queue: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70454}
>
> Tbr: tebbi@chromium.org
> Bug: v8:5269
> Bug: v8:10201
> Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70483}
TBR=tebbi@chromium.org,ishell@chromium.org,victorgomes@chromium.org
Change-Id: Icbd71d744a519a58e49feb917109228631b9d9a3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5269
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467846
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70485}
This is a reland of 5e5eaf7954
This CL fixes the "function returns address of local variable" issue
which GCC was complaining about by using inline assembly instead of
address of a local for getting stack pointer approximation.
Original change's description:
> [csa] Fix semantics of PopAndReturn
>
> This CL prohibits using PopAndReturn from the builtins that
> have calling convention with arguments on the stack.
>
> This CL also updates the PopAndReturn tests so that even off-by-one
> errors in the number of poped arguments are caught which was not the
> case before.
>
> Motivation:
>
> PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
> dropping ALL JS arguments that are currently located on the stack.
> Disallowing PopAndReturn in builtins with stack arguments simplifies
> semantics of this instruction because in case of presence of declared
> stack parameters it's impossible to distinguish the following cases:
> 1) stack parameter is included in JS arguments (and therefore it will
> be dropped as a part of 'pop' number of arguments),
> 2) stack parameter is NOT included in JS arguments (and therefore it
> should be dropped in ADDITION to the 'pop' number of arguments).
>
> This issue wasn't noticed before because builtins with stack parameters
> relied on adapter frames machinery to ensure that the expected
> parameters are present on the stack, but on the same time the adapter
> frame tearing down code was effectively recovering the stack pointer
> potentially broken by the CSA builtin.
>
> Once we get rid of the arguments adapter frames keeping stack pointer
> in a valid state becomes crucial.
>
> Bug: v8:5269, v8:10201
> Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70454}
Tbr: tebbi@chromium.org
Bug: v8:5269
Bug: v8:10201
Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70483}
This reverts commit 5e5eaf7954.
Reason for revert: Failure on V8 Linux gcc https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/8929?
Original change's description:
> [csa] Fix semantics of PopAndReturn
>
> This CL prohibits using PopAndReturn from the builtins that
> have calling convention with arguments on the stack.
>
> This CL also updates the PopAndReturn tests so that even off-by-one
> errors in the number of poped arguments are caught which was not the
> case before.
>
> Motivation:
>
> PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
> dropping ALL JS arguments that are currently located on the stack.
> Disallowing PopAndReturn in builtins with stack arguments simplifies
> semantics of this instruction because in case of presence of declared
> stack parameters it's impossible to distinguish the following cases:
> 1) stack parameter is included in JS arguments (and therefore it will
> be dropped as a part of 'pop' number of arguments),
> 2) stack parameter is NOT included in JS arguments (and therefore it
> should be dropped in ADDITION to the 'pop' number of arguments).
>
> This issue wasn't noticed before because builtins with stack parameters
> relied on adapter frames machinery to ensure that the expected
> parameters are present on the stack, but on the same time the adapter
> frame tearing down code was effectively recovering the stack pointer
> potentially broken by the CSA builtin.
>
> Once we get rid of the arguments adapter frames keeping stack pointer
> in a valid state becomes crucial.
>
> Bug: v8:5269, v8:10201
> Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70454}
TBR=tebbi@chromium.org,ishell@chromium.org
Change-Id: I2673982a8f51cbecf421af11b0ce5ad5031fb406
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5269
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465656
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70458}
This CL prohibits using PopAndReturn from the builtins that
have calling convention with arguments on the stack.
This CL also updates the PopAndReturn tests so that even off-by-one
errors in the number of poped arguments are caught which was not the
case before.
Motivation:
PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
dropping ALL JS arguments that are currently located on the stack.
Disallowing PopAndReturn in builtins with stack arguments simplifies
semantics of this instruction because in case of presence of declared
stack parameters it's impossible to distinguish the following cases:
1) stack parameter is included in JS arguments (and therefore it will
be dropped as a part of 'pop' number of arguments),
2) stack parameter is NOT included in JS arguments (and therefore it
should be dropped in ADDITION to the 'pop' number of arguments).
This issue wasn't noticed before because builtins with stack parameters
relied on adapter frames machinery to ensure that the expected
parameters are present on the stack, but on the same time the adapter
frame tearing down code was effectively recovering the stack pointer
potentially broken by the CSA builtin.
Once we get rid of the arguments adapter frames keeping stack pointer
in a valid state becomes crucial.
Bug: v8:5269, v8:10201
Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70454}
This is a reland of e2408c2521
Changes since last time: also accept CRASH test results. For some
reason, the CHECK failure is detected as a CRASH on mac bots.
Original change's description:
> [regexp] Protect against reentrant RegExpStack use
>
> Irregexp, and in particular the RegExpStack, are not reentrant.
> Explicitly guard against reentrancy.
>
> Bug: chromium:1125934
> Change-Id: I0fc295f6986a89221982e6a2ccefed46193974f6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460820
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70436}
Tbr: yangguo@chromium.org
Bug: chromium:1125934
Change-Id: I2116ca5944c49f6114228d4402847bdd426bdd7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465823
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70441}
Irregexp, and in particular the RegExpStack, are not reentrant.
Explicitly guard against reentrancy.
Bug: chromium:1125934
Change-Id: I0fc295f6986a89221982e6a2ccefed46193974f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460820
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70436}
This is a "minimal" change to achieve the required goal: seeing that
there is only one place where we need to indicate that memory should
be reserved with MAP_JIT, we can add a value to the Permissions enum
instead of adding a second, orthogonal parameter.
That way we avoid changing public API functions, which makes this CL
easier to undo once we have platform-independent w^x in Wasm.
Bug: chromium:1117591
Change-Id: I6333d69ab29d5900c689f08dcc892a5f1c1159b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435365
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70379}
This CL adds a call counter in the WasmExportedFunctionData. The counter
is incremented every time a call to an exported WebAssembly function is
handled through the generic js-to-wasm wrapper.
Bug: v8:10982
Change-Id: Iad40b414b0c7d2f4ab340ff4ebb7b24c60b3a974
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445873
Commit-Queue: Vicky Kontoura <vkont@google.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70336}
Ensure that events are triggered when a module is decoded, compiled,
instantiated and tiered-up.
This is a reland of Ib5883a338c3756c6f3488fbdd7b6861ecc2ba218.
R=clemensb@chromium.orgTBR=adamk@chromium.org
Bug: chromium:1092417
Change-Id: I803ae3db23a5f71f26e8ec118251eccdfc551353
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2425056
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70113}
Ensure that events are triggered when a module is decoded, compiled,
instantiated and tiered-up.
This is a reland of I9dc87957fc03023c5ab1c4f49e865957c8324e1a.
R=clemensb@chromium.org
Bug: chromium:1092417
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Change-Id: Ib5883a338c3756c6f3488fbdd7b6861ecc2ba218
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2367866
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70074}
ceilf and truncf do not preserve the sign bit when its input
is passed by value and the output is rounded to 0:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97086
Change-Id: I10b963e3193f1754f31f3bfc415b8a82d4ae011c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416240
Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#69977}
Since the web-exposed profiler will require COOP/COEP, it is no longer
necessary to perform isolation at the V8 level. Strip the unnecessary
complexity and unreliability of context filtering accordingly.
Bug: chromium:956688, v8:9881, v8:9860
Change-Id: I21a30d51f8daf7565ec95de8c265e9d3b9d10fad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2386144
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69894}
Apple's upcoming arm64 devices will prevent rwx access to memory,
but in turn provide a new per-thread way to switch between write
and execute permissions. This patch puts that system to use for
the WebAssembly subsystem.
The approach relies on CodeSpaceWriteScope objects for now. That
isn't optimal for background threads (which could stay in "write"
mode permanently instead of toggling), but its simplicity makes
it a good first step.
Background:
https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon
Bug: chromium:1117591
Change-Id: I3b60f0efd34c0fed924dfc71ee2c7805801c5d42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2378307
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69791}
Mostly a cleanup for x64.
Also enable two tests for Arm and Arm64 since they do not make use of
JSEntry frames.
Bug: v8:10833
Change-Id: Id6adadf582bdca0076460842ffe4ec856ca99393
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381455
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69634}
Reading the proper pc, fp and sp in a JSEntry frame is in a different
offset than in the regular frames.
Bug: v8:10779, v8:10833
Fixes: v8:10779
Change-Id: I9aec44276fba0aab95b761ab17a16ec3767f4eb8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2369173
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69582}
I forgot to remove them when I removed the old API in
https://chromium-review.googlesource.com/c/v8/v8/+/2369174.
Bug: v8:8116
Change-Id: I74a9670f56d09b7907187d5abcf15d707c8100a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377688
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69569}
Ensure that events are triggered when a module is decoded, compiled,
instantiated and tiered-up.
R=clemensb@chromium.org
Bug: chromium:1092417
Change-Id: I9dc87957fc03023c5ab1c4f49e865957c8324e1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351676
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69508}
To properly test tier-up in the V8 test suite, change the test variant
previously called --turbo-nci-as-highest-tier to
--turbo-nci-as-midtier. As a midtier (between ignition and turbofan),
all major parts of the NCI pipeline (codegen, caching inside the same
native context, tier-up) are exercised by test suite.
Bug: v8:8888
Change-Id: Ic8ee2f3e3d72768c3869f5e0b25800dd0a5f25b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2361462
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69501}
Port 2547e1cece
Original Commit Message:
Since the compilation progress was never initialized on deserialization,
tier down was always skipped on such modules.
By initializing to the expected state after deserialization (i.e. all
code as TurboFan code), we make sure that later recompilation works as
expected.
R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Iab66ca0d1bfb36cfee56ccd85720d4c5552eb9c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2363270
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69465}
This is a reland of 60ee70bb40.
The wasm c-api flakes were fixed in https://crrev.com/c/2349293.
Original change's description:
> [wasm] Ensure that only TurboFan code is serialized
>
> We have the implicit assumption that Liftoff code will never be
> serialized, and we start relying on that when implementing new features
> (debugging, dynamic tiering).
>
> This CL makes the serializer fail if the module contains any Liftoff
> code. Existing tests are changed to ensure that we fully tiered up
> before serializing a module (similar to the logic in Chromium).
> The "wasm-clone-module" test needs to serialize the module before
> enabling the debugger.
>
> Note that chrome currently only serializes a module after it fully
> tiered up, so that should be fine. If other embedders need the ability
> to serialize a module in an arbitrary state, we will have to fix this
> later. With this CL we will be on the safe side though and (gracefully)
> fail serialization instead of accidentally serializing Liftoff code.
>
> R=ahaas@chromium.org
>
> Bug: v8:10777
> Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69276}
Bug: v8:10777
Change-Id: I2a7c1429812ca46d88a2902b8e0a7b7e3d638b56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349290
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69335}
This reverts commit 60ee70bb40.
Reason for revert: wasm-api-tests/WasmCapiTest.Serialize starts flaking: https://crbug.com/v8/10784
Original change's description:
> [wasm] Ensure that only TurboFan code is serialized
>
> We have the implicit assumption that Liftoff code will never be
> serialized, and we start relying on that when implementing new features
> (debugging, dynamic tiering).
>
> This CL makes the serializer fail if the module contains any Liftoff
> code. Existing tests are changed to ensure that we fully tiered up
> before serializing a module (similar to the logic in Chromium).
> The "wasm-clone-module" test needs to serialize the module before
> enabling the debugger.
>
> Note that chrome currently only serializes a module after it fully
> tiered up, so that should be fine. If other embedders need the ability
> to serialize a module in an arbitrary state, we will have to fix this
> later. With this CL we will be on the safe side though and (gracefully)
> fail serialization instead of accidentally serializing Liftoff code.
>
> R=ahaas@chromium.org
>
> Bug: v8:10777
> Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69276}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: Ic1349375bd562bb0a2724c39c27ef3247461c97b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10777
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2342845
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69284}
We have the implicit assumption that Liftoff code will never be
serialized, and we start relying on that when implementing new features
(debugging, dynamic tiering).
This CL makes the serializer fail if the module contains any Liftoff
code. Existing tests are changed to ensure that we fully tiered up
before serializing a module (similar to the logic in Chromium).
The "wasm-clone-module" test needs to serialize the module before
enabling the debugger.
Note that chrome currently only serializes a module after it fully
tiered up, so that should be fine. If other embedders need the ability
to serialize a module in an arbitrary state, we will have to fix this
later. With this CL we will be on the safe side though and (gracefully)
fail serialization instead of accidentally serializing Liftoff code.
R=ahaas@chromium.org
Bug: v8:10777
Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69276}
Just like the optimized code cache, the compiler should check the
isolate cache for NCI code objects and return them if they exist.
Drive-by: Skip additional tests to fix the nci_as_highest_tier test
variant. These are related to interactions with deoptimization, which
NCI code doesn't fully support yet.
Bug: v8:8888
Change-Id: I6253811f96993796cfc38fff0da7ffb4f1a5eb24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339095
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69251}
PersistentHandles were attached to the LocalHeap when passed in through
the constructor but not when created inside LocalHeap using
EnsurePersistentHandles.
Bug: v8:10315
Change-Id: Id24d36c935776cb0b643521c465763da7fbffd06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326630
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69167}
Due to dynamic map checks we generate different code and the pattern
fails. As a note, the other tests have already been disabled for
TurboProp.
Bug: v8:9684, v8:9820
Change-Id: Ib8be11ae10bc801116d6a17d1c6b08d8026287b3
Fixes: v8:9820
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2328784
Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69140}
With work on NCI proceeding, it makes sense to test multiple
pipeline configurations.
The nci variant (passes --turbo-nci) now spawns dedicated NCI
compilation jobs and inserts generated code into the code cache.
The nci_as_highest_tier variant (passes --turbo-nci-as-highest-tier)
simply replaces TF with NCI code (no extra jobs, no extra caching).
This mode stresses NCI generated code more than the nci variant, in
which NCI code only runs on cache hits.
Bug: v8:8888
Change-Id: I4c2a43cce5271a6c288e7aba195dcc9daed6af9d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299361
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68964}
When creating a new JSFunction (either through Factory::NewFunction or
the FastNewClosure builtin), install the cached Code object if one
exists. In the former, this happens explicitly; in the former implicitly
through %CompileLazy.
Drive-by: Clean up nci tracing methods.
Drive-by: Rename maybe_has_... to may_have_cached_code.
Bug: v8:8888
Change-Id: I98d87df10df496c45749b3fd76c072c36af45b68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2294662
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68863}
Native context independent code generation should, at the moment, not
use any collected feedback.
We implement this by returning InsufficientFeedback from the heap
broker's ReadFeedbackForX methods if currently compiling nci code.
Thus all feedback.IsInsufficient() calls inside the compiler will
return true (disabling feedback-based optimizations).
FeedbackSource::IsValid() (used in generic lowering) can still return
true.
Bug: v8:8888
Change-Id: I198b6457276073e7376c777b206c50726f1b3645
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284494
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68726}
OldGenerationAllocationCounter() needs to be invoked in safepoint,
otherwise invocation races with background threads incrementing the
counter.
First landed in https://crrev.com/c/2235544 and relanded in https://crrev.com/c/2259854 because of regressions. This CL also invokes UpdateNewSpaceAllocationCounter() in the safepoint.
Bug: v8:10315
Change-Id: I6104bed0aad848250feecfe51d6d849b184a8842
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2260560
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68614}
Test has flaky data race and will be fixed after branch to avoid
regressions.
Bug: v8:10637, v8:10315
Change-Id: Iddbbd91701aea622803146b84c9a9aa334bda927
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2263155
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68506}
Let's see if this is still flaky after almost 5 years.
Bug: v8:4573
Change-Id: I4cd2779b2c4aefc7bb20597db2fccc0e7e7c39c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2255467
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68465}
... for nci code, in which several phases of the compiler are not
active:
LowerJSCreateCatchContext
LowerJSCreateEmptyLiteralObject
LowerJSCreateIterResultObject
LowerJSCreateWithContext
LowerJSGetIterator
LowerJSGetTemplateObject
With this change, the nci variant passes the test suite. Tests
relying on turbofan-specific behavior (e.g. deopts) are skipped.
Bug: v8:8888
Change-Id: I709178241e9b25e7480a39b4fb64bdcf576483be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2245604
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68381}
