This is to establish a naming rule for Torque-generated files:
- If the file is called foo/bar-tq..., then it is derived from a
file foo/bar.tq
- Otherwise it doesn't belong to a specific .tq file.
So far, we attached -tq to all Torque-generated file names, where it
sometimes corresponded to a .tq file name and sometimes not.
It is not necessary to add -tq to file names to indicate that they are
Torque-generated, since they are already in a directory called
torque-generated, and we always refer to them as
"torque-generated/filename", so there is no confusion even though some
files now have the same name as a corresponding hand-written file, for
example factory.cc.
TBR: hpayer@chromium.org
Bug: v8:7793
Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70060}
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 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}
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}
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}
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}
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}
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}
Changes:
- Rename IsSignatureEqual -> MatchesSignature for consistency
- Add WasmInstanceObject field to WasmTableObject.
- Improve some error messages related to tables in
function-body-decoder-impl.h.
- Introduce WasmTable::IsValidTableType. Use it wherever appropriate.
- Overload equality operators in HeapType to work with
HeapType::Representation.
- Rename DynamicTypeCheckRef -> TypecheckJSObject.
- Handle WasmCapiFunctions in TypecheckJSObject.
- Use TypecheckJSObject in WasmTableObject::IsValidElement.
- A few more minor improvements.
Bug: v8:9495
Change-Id: I2867dd3486d7c31717ac26b87a50e15cf2b898be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416491
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70001}
This reverts commit 8b60d8fcbf.
Reason for revert: Flaky on windows: https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/27302
Original change's description:
> Reland "[cpu-profiler] Log OSR code when starting the profiler"
>
> This is a reland of f696528189
>
> Updated the test:
> 1. Set profiling interval to 100us to get 10x the samples
> 2. Guarantee we spend at least 1ms per iteration, instead of only
> bailing out if we spend more than 1ms. This gives us enough samples on
> release mode.
> 3. Increase the time spent profiling optimized code by 50% to make sure
> we have a big enough difference.
>
> With 1000 iterations I didn't see any flakes locally so this looks solid
> now.
>
> Original change's description:
> > [cpu-profiler] Log OSR code when starting the profiler
> >
> > OSR code doesn't hang off any JSFunction or SFI, so we missed it when
> > starting up the profiler. This meant we didn't properly attribute
> > ticks to SFI code. The ticks ended up going to the caller instead.
> >
> > There is a weak cache of OSR code per native context, so iterate that
> > on profiler startup and log all the code objects.
> >
> > Change-Id: I2e9738b86a488b37f36ac89803561607dc76f745
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414216
> > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> > Reviewed-by: Mythri Alle <mythria@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#69964}
>
> Change-Id: Ib506e88b546008e462967259763bbf985b74b462
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418092
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69990}
TBR=mythria@chromium.org,petermarshall@chromium.org,dinfuehr@chromium.org
Change-Id: Ie3272c4fd297ca6f10a47c3fe8826e226a9f0545
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418714
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69999}
This reverts commit af5f437cd9.
Reason for revert: Seems to break TSAN - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33286?
Original change's description:
> [heap] Fix tracking of code pages for V8 stack unwinder
>
> 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 spage 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 introduces a new page flag for marking pages that are borrowed
> during compaction and skips them in MergeLocalSpace.
>
> Bug: v8:10900
> Change-Id: I786dc5747bd7c785ae58dfd8b841c00774efb15e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416500
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69992}
TBR=ulan@chromium.org,jkummerow@chromium.org,dinfuehr@chromium.org
Change-Id: I13f8b64014750af95423166152dc9bee8cec12d0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10900
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418395
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69993}
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 spage 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 introduces a new page flag for marking pages that are borrowed
during compaction and skips them in MergeLocalSpace.
Bug: v8:10900
Change-Id: I786dc5747bd7c785ae58dfd8b841c00774efb15e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416500
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69992}
This is a reland of f696528189
Updated the test:
1. Set profiling interval to 100us to get 10x the samples
2. Guarantee we spend at least 1ms per iteration, instead of only
bailing out if we spend more than 1ms. This gives us enough samples on
release mode.
3. Increase the time spent profiling optimized code by 50% to make sure
we have a big enough difference.
With 1000 iterations I didn't see any flakes locally so this looks solid
now.
Original change's description:
> [cpu-profiler] Log OSR code when starting the profiler
>
> OSR code doesn't hang off any JSFunction or SFI, so we missed it when
> starting up the profiler. This meant we didn't properly attribute
> ticks to SFI code. The ticks ended up going to the caller instead.
>
> There is a weak cache of OSR code per native context, so iterate that
> on profiler startup and log all the code objects.
>
> Change-Id: I2e9738b86a488b37f36ac89803561607dc76f745
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414216
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69964}
Change-Id: Ib506e88b546008e462967259763bbf985b74b462
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418092
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69990}
This reverts commit 1aa9ab7384.
The reverted CL chain had an issue where ThinStrings could accidentally
end up in compilation artifacts, causing issues down the line with ICs
that expected direct internalized strings.
The reason for this bug was that forward references to internalized
strings were resolved before PostProcessNewObject. When this happened,
the internalized string A would be written to the field where it was
previously deferred, then PostProcessNewObject would change string A to
string A', and update string A to a ThinString. This means any _future_
back references to A would see the ThinString and follow it to receive
A', but any _past_ forward references would keep pointing to the
ThinString A.
This reland fixes this by preventing InternalizedString deferral, so
that all references to InternalizedStrings are back references. It also
adds some additional verification to the heap verifier that constant
pools and object boilerplate descriptors aren't allowed to hold thin
strings.
This patch also fixes an additional bug in the original CL, where weak
forward refs weren't being serialized with a weak prefix.
Original change's description:
> Revert recent de/serializer related changes
>
> They are suspected to be causing Canary crashes, confirmed through
> local reverts and repro attempts.
>
> This reverts:
> - "Reland "[serializer] Change deferring to use forward refs""
> commit 76d684cc82.
> - "Reland "[serializer] Remove new space""
> commit 81231c23a9.
> - "[serializer] Clean-up and de-macro ReadDataCase"
> commit c06d24b915.
> - "[serializer] DCHECK deserializer allocations are initialized"
> commit fbc1f32d8e.
>
> Bug: chromium:1128872
> Change-Id: Id2bb3b8fac526fdf9ffb033222ae08cd423f8238
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414220
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69955}
Tbr: jgruber@chromium.org,dinfuehr@chromium.org
Bug: chromium:1075999
Bug: chromium:1127610
Bug: chromium:1128848
Bug: chromium:1128872
Bug: chromium:1128957
Change-Id: I8b7bbabf77eb8cb942a28316afbfaa5f9a0aa4cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418101
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69988}
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}
This reverts commit f696528189.
Reason for revert: Test is flaky: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64/39092
Original change's description:
> [cpu-profiler] Log OSR code when starting the profiler
>
> OSR code doesn't hang off any JSFunction or SFI, so we missed it when
> starting up the profiler. This meant we didn't properly attribute
> ticks to SFI code. The ticks ended up going to the caller instead.
>
> There is a weak cache of OSR code per native context, so iterate that
> on profiler startup and log all the code objects.
>
> Change-Id: I2e9738b86a488b37f36ac89803561607dc76f745
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414216
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69964}
TBR=mythria@chromium.org,petermarshall@chromium.org,dinfuehr@chromium.org
Change-Id: I1e69f8af88d901bab6f257652d3536d24a4777f9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2415994
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69969}
OSR code doesn't hang off any JSFunction or SFI, so we missed it when
starting up the profiler. This meant we didn't properly attribute
ticks to SFI code. The ticks ended up going to the caller instead.
There is a weak cache of OSR code per native context, so iterate that
on profiler startup and log all the code objects.
Change-Id: I2e9738b86a488b37f36ac89803561607dc76f745
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414216
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69964}
Add lowering for I64x2 in S128Const and converting Int64x2 to
Int32x2.
Bug: v8:10507
Change-Id: I5bc40ae135fa00e31e901337b1a315f6ead14b02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410800
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69960}
They are suspected to be causing Canary crashes, confirmed through
local reverts and repro attempts.
This reverts:
- "Reland "[serializer] Change deferring to use forward refs""
commit 76d684cc82.
- "Reland "[serializer] Remove new space""
commit 81231c23a9.
- "[serializer] Clean-up and de-macro ReadDataCase"
commit c06d24b915.
- "[serializer] DCHECK deserializer allocations are initialized"
commit fbc1f32d8e.
Bug: chromium:1128872
Change-Id: Id2bb3b8fac526fdf9ffb033222ae08cd423f8238
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414220
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69955}
dst might not be the same as src0 (since we don't define them to be
equals in the instruction-selector if AVX is enabled), so the minps
and maxps comparisons were incorrect.
I found this while trying to run some spec tests, so not adding any
unittest, eventually when the spec tests are enabled, this will be
covered.
Bug: v8:10835
Change-Id: I4fbc1dfe949e4137e057e73c0d5dfb8534a00b8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411484
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69953}
While the sampler checked if the sampled thread had the Isolate locked
(if locks are being used) under Linux, the check was not done under
Windows (or Fuchsia) which meant that in a multi-threading application
under Windows, thread locking was not checked making it prone to seg
faults and the like as the profiler would be using isolate->js_entry_sp
to determine the stack to walk but isolate->js_entry_sp is the stack
pointer for the thread that currently has the Isolate lock so, if the
sampled thread does not have the lock, the sampler woud be iterating
over the wrong stack, one that might actually be actively changing on
another thread. The fix was to move the lock check into CpuSampler
and Ticker (--prof) so all OSes would do the correct check.
The basic concept is that on all operating systems a CpuProfiler, and
so its corresponding CpuCampler, the profiler is tied to a thread.
This is not based on first principles or anything, it's simply the
way it works in V8, though it is a useful conceit as it makes
visualization and interpretation of profile data much easier.
To collect a sample on a thread associated with a profiler the thread
must be stopped for obvious reasons -- walking the stack of a running
thread is a formula for disaster. The mechanism for stopping a thread
is OS-specific and is done in sample.cc. There are currently three
basic approaches, one for Linux/Unix variants, one for Windows and one
for Fuchsia. The approaches vary as to which thread actually collects
the sample -- under Linux the sample is actually collected on the
(interrupted) sampled thread whereas under Fuchsia/Windows it's on
a separate thread.
However, in a multi-threaded environment (where Locker is used), it's
not sufficient for the sampled thread to be stopped. Because the stack
walk involves looking in the Isolate heap, no other thread can be
messing with the heap while the sample is collected. The only ways to
ensure this would be to either stop all threads whenever collecting a
sample, or to ensure that the thread being sampled holds the Isolate
lock so prevents other threads from messing with the heap. While there
might be something to be said for the "stop all threads" approach, the
current approach in V8 is to only stop the sampled thread so, if in a
multi-threaded environment, the profiler must check if the thread being
sampled holds the Isolate lock.
Since this check must be done, independent of which thread the sample
is being collected on (since it varies from OS to OS), the approach is
to save the thread id of the thread to be profiled/sampled when the
CpuSampler is instantiated (on all OSes it is instantiated on the
sampled thread) and then check that thread id against the Isolate lock
holder thread id before collecting a sample. If it matches, we know
sample.cc has stop the sampled thread, one way or another, and we know
that no other thread can mess with the heap (since the stopped thread
holds the Isolate lock) so it's safe to walk the stack and collect data
from the heap so the sample can be taken. It it doesn't match, we can't
safely collect the sample so we don't.
Bug: v8:10850
Change-Id: Iba6cabcd3e11a19c261c004103e37e806934dc6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411343
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69952}
This CL is non-functional by itself and it prepares extending
IsJSCompatibleSignature to wasm-gc types.
Bug: v8:7748
Change-Id: I0bf02d55e83ed020ef63b4eedf641d9405c3a689
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2413251
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69947}
With the --always_promote_young_mc flag the mark-compact collector
cannot gracefully handle allocation failures when evacuating the young
generation. In some scenarios this causes OOM crashes without invoking
NearHeapLimitCallback.
This CL ensures that the young generation is evacuated before the old
generation because old generation evacuation can be aborted if needed.
Additionally, the CL cleans up usages of CanExpandOldGeneration.
Bug: v8:10843
Change-Id: I50d83912137afa3d3dac797dd4c6bddb51612334
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404829
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69937}
For "else" and "catch" statements, the Ref to the end label should only
be added if the current block is unreachable, not the parent block.
In the added regression test, the "true" block ends in an unreachable
state with a stack height less than the target height of the end label.
This is valid due to the semantics of unreachable code, but we should
not add the Ref in this case because its stack height is invalid.
R=clemensb@chromium.org
Fixed: chromium:1092130
Change-Id: Iebaf5e7d6516278ccd3c8268ac331069e109d882
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412181
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69934}
Since the string-table's data pointer is written inside a mutex, but
read outside of it, we need to acq/rel access to it.
There's no support in C++ for an std::atomic<std::unique_ptr>, so this
patch changes the std::unique_ptr<Data> into a std::atomic<Data*>, and
handles the deletion manually. StringTable::Data still uses
std::unique_ptr as the general pointer-passing contract, we just
carefully set and release the unique_ptrs when accessing and setting
the StringTable's atomic Data pointer.
Change-Id: I711a56825e2f5f9b2db63d1874e09c2627af54b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410057
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69932}
Making test failures more convenient to debug than simply failing
a .ToHandleChecked() call.
Change-Id: Ieb4553bec8886d1a4eb0dbf0c7bc53ac6435a82c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412528
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69928}
Implement f32x4 and f64x2 nearest, trunc, ceil, and floor.
These instructions were accepted into the proposal [0], this change
removes all the ifdefs and todo guarding the prototypes, and moves these
instructions out of the post-mvp flag.
[0] https://github.com/WebAssembly/simd/pull/232
Bug: v8:10906
Change-Id: I44ec21dd09f3bf7cf3cae5d35f70f9d2c178c4e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2406547
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69923}
If code is deoptimized while CPU profiling, a deoptimization event
record is sent to the profiler. But if the profiler could not find
the associated CodeMap entry in CodeDeoptEventRecord::UpdateCodeMap
it would simply return without freeing the deopt_frames array.
This change frees the deopt_frames array no matter what in
CodeDeoptEventRecord::UpdateCodeMap, eliminating a storage leak.
Bug: v8:10861
Change-Id: I4e68566bb91dff13b38e255ddfed24b85b7a1d57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2386332
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69901}
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}
all_true requires the input to be of the respective type, but the
final result is always a Int32x4 with a single node. So keep
the replacement type of all_true (and any_true) nodes to be Int32x4,
and use a helper method to decide what SimdType the input should
be replaced with.
Also split up any_true and all_true for readability.
Bug: v8:10507
Change-Id: I58ca50ffffcbca3ec77bbae1371ddd179925fc96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2405803
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69890}
Add a separate mutex for the {debug_side_tables_} field. This ensures
that we can use {GetDebugSideTableIfExists} even if {mutex_} is already
locked.
R=ahaas@chromium.org
CC=clemensb@chromium.org
Bug: v8:10889
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: Icb67c45aec0cf66814705b83532f4833f36738e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2402879
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69888}
CL in preparation of writing JavaScript-based log parsing tests.
- Return both temporary and normal log file in
Log::TearDownAndGetLogFile
- Add file_name accessor to Logger and Log classes
- Use separate Log::WriteLogHeader method
- Remove unused logger_ instance variable from Log
Bug: v8:10668
Change-Id: Ie1f6f92cc6c55fd1dc664cac95f481bc29da7e18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2407773
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69879}
This commit adds a check in Heap::AllocateRaw when setting the
large_object variable, when the AllocationType is of type kCode, to
take into account the size of the CodeSpace's area size.
The motivation for this change is that without this check it is
possible that size_in_bytes is less than 128, and hence not considered
a large object, but it might be larger than the available space
in code_space->AreaSize(), which will cause the object to be created
in the CodeLargeObjectSpace. This will later cause a segmentation fault
when calling the following chain of functions:
if (!large_object) {
MemoryChunk::FromHeapObject(heap_object)
->GetCodeObjectRegistry()
->RegisterNewlyAllocatedCodeObject(heap_object.address());
}
We (Red Hat) ran into this issue when running Node.js v12.16.1 in
combination with yarn on aarch64 (this was the only architecture that
this happed on).
Bug: v8:10808
Change-Id: I0c396b0eb64bc4cc91d9a3be521254f3130eac7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390665
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69876}
We need to construct Float32 nodes for f32x4, using Word32 operators
will cause the wrong register to be allocated, triggering a CHECK
failure.
Bug: v8:10507
Change-Id: I70842f1d61b90fed2407ee52af4bc5a6b1b82ba6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2399050
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69856}
F32x4 and F64x2 pmin and pmax were accepted into the proposal [0], this
removes all the ifdefs and todo guarding the prototypes, and moves these
instructions out of the post-mvp flag.
[0] https://github.com/WebAssembly/simd/pull/122
Bug: v8:10904
Change-Id: I4e0c2f29ddc5d7fc19a209cd02b3d369617574a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2405802
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69855}
... by unparking the local heap before accessing the handles.
Bug: v8:7790
Change-Id: I0910fd8ad2a1e9cbbf312acb4f26358a09891f0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404455
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69852}
FLAG_local_heaps needs to be set before creating the context, otherwise
the StressConcurrentAllocatorTask is already started. Setting the flag
then races with background thread, which checks FLAG_local_heaps while
creating LocalHeap.
Bug: v8:10315
Change-Id: If6de748ec174dffb94a2582d24e37d24586ee95a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404823
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69850}
