The tests are flaky because of missing safepoint information for stack
checks. Adding the safepoint information there is not trivial though,
so I disable these tests for now to keep at least the bots green.
An alternative would be to revert the CLs that add safepoints in the
first place. However, I would prefer to avoid the overhead that would
be caused by it. The implementation is completely hidden behind a flag,
so it does not have impact on production code.
R=clemensb@chromium.org
Bug: v8:10929
Change-Id: I38c0e3c3806de2cc39ba26bc3b47c2ea8d1cf81a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423705
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70056}
Otherwise concurrent allocation might start incremental marking, which
would then mark the global handle.
Bug: v8:10315
Change-Id: Ibc681b001847a7c52e9fd8a0420e42a0d0ecfbda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424004
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70054}
This flag has no uses in any tests, and it's hard to image a use case
for debugging or similar.
R=ahaas@chromium.org
Bug: v8:10933
Change-Id: I2e96187e4410805824d213e9a9df152b54dd3fb2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421825
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70052}
This CL improves the condition that checks all parameters received
from JavaScript when calling an exported WebAssembly function
to determine whether they can be transformed without calls to
built-in functions. The condition is now updated to stop checking
if one parameter that cannot be transformed quickly
is encountered.
Bug: v8:10943
Change-Id: If199aa8d2ffcef86f973c23d9663f8091dfced8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423713
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Vicky Kontoura <vkont@google.com>
Cr-Commit-Position: refs/heads/master@{#70050}
This reverts commit 4a2b2b2e56.
Reason for revert: Speculative revert due to https://ci.chromium.org/p/chromium/builders/try/linux-rel/495075?
Original change's description:
> [Heap]: Marking use Jobs.
>
> StopRequest is removed in favor of:
> COMPLETE_TASKS_FOR_TESTING -> JoinForTesting()
> PREEMPT_TASKS -> Pause()
> COMPLETE_ONGOING_TASKS now has the same behavior as PREEMPT_TASKS
> - we should avoid waiting on the main thread as much as possible.
>
> Change-Id: Icceeb4f0c0fda2ed234b2f26fe308b11410fcfb7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376166
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70037}
TBR=ulan@chromium.org,etiennep@chromium.org
Change-Id: I63f24bffa0f56c6ffa1d1977fc4fb8a76b6f3ba2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423722
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70049}
Choose the page size based on V8_HOST_ARCH_ARM64 (i.e. we're building
an arm64 binary) instead of V8_TARGET_ARCH_ARM64 (i.e. V8's compilers
are emitting arm64 instructions, which is the case in simulator builds
as well).
Drive-by:
- use V8_TARGET_OS_MACOSX instead of __APPLE__
- drop implementation difference between AllocatePageSize and
CommitPageSize on POSIX (they must return the same value anyway)
This continues and obsoletes the work at
https://chromium-review.googlesource.com/c/v8/v8/+/2314102 .
Bug: chromium:1107945, chromium:1128932
Change-Id: Iaaa509dd496ff581ddda4d957bc3d35d806cf81e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421817
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70047}
The actual fix is in LoadIC::ComputeHandler (checking
lookup_start_object == holder instead of receiver == holder) + the
LookupIterator changes for preserving lookup_start_object.
The rest is renaming / refactoring.
Bug: v8:9237, chromium:1127653
Change-Id: Ieef46fb46ababa79623951c48639429c5b552d2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414039
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70045}
StressConcurrentAllocatorTask now checks whether tear down was started
for the isolate to avoid allocation failures.
As a drive-by change remove the unused method
ConcurrentAllocator::PerformCollectionAndAllocateAgain.
Bug: v8:10315
Change-Id: Iba329ebbd782e9f8f11e9b8ec644bf28ab9c80ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423703
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70044}
Added scopes to diallow/allow GCs from happening using a DCHECK. It is
stricter than DisallowHeapAllocation, since this also doesn't allow
safepoints.
As soon as Turbofan is ready, we can replace all usages of
DisallowHeapAllocation with DisallowGarbageCollection.
Bug: v8:10315
Change-Id: I12c144ec099d9af57d692ff343adbe7aec46c0c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362960
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70042}
Building and running tests with v8_enabled_concurrent_marking=false
currently produces two failures:
1) Segmentation fault on attempt to mark a read-only object.
This is fixed by changing MarkBit::Set to be a no-op if the object
is already marked (which is the case for the readonly space).
2) Missing write-barrier due to bogus condition in the bailout.
The barrier can be skipped only if the host object is not marked yet.
This also disables two concurrent allocation tests that rely on
concurrent marking write-barrier.
Bug: v8:10875
Change-Id: Ib3a238fc34c8f20c697470e0bd4ac427fb4bdc0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421816
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70041}
Instantiating a module that contains a function (exported) with a v128
in its signature is fine, but then later calling it will trap.
So v128 values are technically not callable from JS, but we can give it
a default argument of 0, and will later trap anyway. This is useful when
fuzzers generate functions with v128 in the signature of the main
function that we then later try to call.
Bug: chromium:1129068
Change-Id: I93f239a0355b8059e25b8bd5f1274d151d71ee11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2419657
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70038}
StopRequest is removed in favor of:
COMPLETE_TASKS_FOR_TESTING -> JoinForTesting()
PREEMPT_TASKS -> Pause()
COMPLETE_ONGOING_TASKS now has the same behavior as PREEMPT_TASKS
- we should avoid waiting on the main thread as much as possible.
Change-Id: Icceeb4f0c0fda2ed234b2f26fe308b11410fcfb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376166
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70037}
Avoid resetting log flags as this could cause data races with
allocating background threads.
Bug: v8:10315
Change-Id: I7be01ff54e349652f182b944ed3f3366d1239ad7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421814
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70036}
Test was asserting heap size before and after GC. With background
thread allocation those assertions might not hold.
Bug: v8:10315
Change-Id: I4f8c0f6d0b80040b3c89f85e801416abb29ed30e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421999
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70034}
This CL introduces a fast path for transforming JavaScript
parameters to WebAssembly when calling an exported WebAssembly
function from JavaScript.
A transformation is considered fast when it does not require a call
to a built-in function, thus spilling registers for the call can be
avoided.
Bug: v8:10943
Change-Id: I5563bfdf77a68bef7ab8afc6d0f4ab2d2ea67bd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418857
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Vicky Kontoura <vkont@google.com>
Cr-Commit-Position: refs/heads/master@{#70033}
Changes:
- When checking if a table is a function table, check for subtyping to
funcref instead of equality.
- Add WasmModuleObject argument to GetFunctionTableEntry.
- Implement WasmTableObject::Get/Set for all legal table types.
- Factor out SetFunctionTableEntry from WasmTableObject::Set.
- Write unittests and JS tests.
Bug: v8:9495
Change-Id: I4f0c7a7013f17c561afb3039c5e0811634a4d313
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416387
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70032}
Remove the hack introduced in https://crrev.com/c/2412176, use the
existing {ValueTypeToConstantName} function instead.
R=ahaas@chromium.org
Bug: chromium:1127717
Change-Id: I4ac50346825d7b00ea8dadccd7798a273ae84499
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421568
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70028}
Bug: v8:7790
Change-Id: Ibe41dcc3d1717326b8ce7bf3491bf32a8d0882b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421810
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70027}
Assertions are implemented with the new ASSERTION instruction. The nfa
interpreter evaluates the assertion based on the current context in the
subject string every time a thread executes ASSERTION. This is
analogous to what re2 and rust/regex do.
Alternatives to this approach:
- The interpreter could calculate eagerly for all assertion types
whether they are satisfied whenever the current input position is
advanced. This would make evaluating the ASSERTION instruction itself
cheaper, but at the cost of making every advance in the input string
more expensive. I suspect this would be slower on average because
assertions are not that common that we typically evaluate >= 2
assertions at every input position.
- Assertions in a regexp could be desugared into CONSUME_RANGE
instructions, so that no new instruction would be necessary. For
example, the word boundary assertion \b is satisfied at a given
position/state if we have just consumed a word character and will
consume a non-word character next, or vice-versa. The tricky part
about this is that the assertion itself should not consume input, so
we'd have to split (automaton) states according to whether we've
arrived at them via a word character or not. The current compiler is
not really equipped for this kind of transformation. For {start,end}
of {line,file} assertions, we'd need to introduce dummy characters
indicating start/end of input (say, 0x10000 and 0x10001) which we feed
to the interpreter before respectively after the actual input.
I suspect that this approach wouldn't make much of a difference for
NFA execution. It would likely speed up (lazy) DFA execution though
because assertions would be dealt with in the fast path.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: Ic2012c943e0ce54eb8662789fb3d4c1b6cd8d606
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398644
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70026}
Return MaybeHandle directly instead of converting to Handle first and
then back to MaybeHandle.
Bug: v8:10315
Change-Id: I7d0b67ea3931ad4eba48fc58d934d5722ff70905
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418402
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70025}
When a compaction space allocates a new code page, that pages needs to
be added to the Isolate::code_pages_ array used for stack unwinding.
Since the array is owned by the main thread, compaction thread cannot
directly modify it. Because of that code pages are added upon merging
of the compaction space to the main space in MergeLocalSpace.
The bug was that all code pages coming from the compaction space
were added to the code_pages_ array. However, some of the pages are
not newly allocated but merely borrowed from the main space.
This CL keeps track of all newly allocated paged by a compaction space.
Bug: v8:10900
Change-Id: Iff3ff5d608df60fb752d2e0ffc29e51f2d967936
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418718
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70023}
Since the flag is enabled by default, it is more useful to have the
reverse implications so that disabling the flag is guaranteed to work.
Bug: v8:10315
Change-Id: I191c35682442925f3fed691460d074ba6715fc99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2409498
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70022}
That DCHECK could fail even though GC was in the right state. It could
happen that the first load gets the old value NOT_IN_GC, since this
isn't TEAR_DOWN a second load needs to be performed. The load then
returns TEAR_DOWN but that doesn't match NOT_IN_GC either.
Fix this by only loading gc_state() once.
Bug: v8:10315
Change-Id: Ibcad540fa4d5f578c9936c472b294bbccebdc09a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418719
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70021}
For js frame, we want to display currently executing function.
Change-Id: If33b04279dafdf6e4834bfb6c7240e8e7e799fc7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411483
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70018}
Rolling v8/build: 153ad0b..d77db9e
Rolling v8/third_party/aemu-linux-x64: QxDL1Bk85zKmALn9xHGhro_uZAytSTHjJ--QwZLaT7oC..UncMpcoIeFj9FKkqbpkwnPCh8YmqHZcucJu-mi7jF1MC
Rolling v8/third_party/depot_tools: d949c91..244d770
Rolling v8/third_party/jinja2: 61cfe2a..a82a494
Rolling v8/tools/luci-go: git_revision:b022173f8069cf8001d4cf2a87ce7c5f0eae220f..git_revision:83c3df996b224edf5061840744395707a0e513e7
Rolling v8/tools/luci-go: git_revision:b022173f8069cf8001d4cf2a87ce7c5f0eae220f..git_revision:83c3df996b224edf5061840744395707a0e513e7
Rolling v8/tools/luci-go: git_revision:b022173f8069cf8001d4cf2a87ce7c5f0eae220f..git_revision:83c3df996b224edf5061840744395707a0e513e7
TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: I3305d8fa9f2a741f1f6fdd14b9754f4f42b76bc9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2419992
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#70014}
The DCHECK is only guaranteed to hold after checking that is_logging()
still returns true.
Bug: v8:10315
Change-Id: Ia43657faffa4c7eda70c95a446bee1389d08e6fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418713
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70013}
This reverts commit c0564971ac.
Reason for revert: Speculative revert, ASAN is failing consistently:
https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20ASAN/15103
Original change's description:
> [parser] Use SmallVector(1) for DeclarationParsingResult::declarations
>
> Typically we'll parse a single declaration when parsing variable declarations.
> Using on-stack storage rather than std::vector that requires malloc is much
> more efficient.
>
> Change-Id: Id99515bb4ce7ea2dae46498f8f9f9d49c33c7353
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418393
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69995}
TBR=leszeks@chromium.org,verwaest@chromium.org
Change-Id: I6e46c058f16c965e905f20b8df473a8fb22cc6cc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2419037
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70011}
This reverts commit cfe9544aa6.
Reason for revert: Some spec tests fail:
https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/15933
Original change's description:
> [wasm-simd][scalar-lowering] Enable some spec tests
>
> These tests can now be enabled as we implemented more scalar lowering
> support.
>
> Bug: v8:10507
> Change-Id: Ida5f896300e074db079ec24720302729b0582d9d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411774
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70006}
TBR=bbudge@chromium.org,zhin@chromium.org
Change-Id: Idb2da40178860f045ffab9ab5b2c8b1f2ebafcf6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10507
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2419036
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70010}
Cast to int32_t after checking the range.
Bug: v8:10921
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng,v8_linux64_asan_rel_ng,v8_linux64_tsan_isolates_rel_ng,v8_linux64_msan_rel_ng,v8_linux64_tsan_rel_ng,v8_mac64_asan_rel_ng,v8_win64_asan_rel_ng,v8_linux64_gcc_compile_dbg,v8_linux_gcc_compile_rel,v8_linux_gcc_rel_ng,v8_linux64_gc_stress_custom_snapshot_dbg_ng,v8_linux_arm64_gc_stress_dbg_ng,v8_linux_gc_stress_dbg_ng,v8_mac64_gc_stress_dbg_ng;luci.chromium.try:linux_chromium_ubsan_rel_ng
Change-Id: I9c3631a2f3aa34bc9c87a6f40a2888b38832978c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414622
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70008}
