To let the user do special handling on the main thread e.g. Scavenging
uses different tracing categories for background/foreground threads.
Change-Id: I6c9187fd6201b5b81cd83727727fda49fcf7ff68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2405797
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69978}
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}
For the standalone library, some platform implementations might not
support non-nested tasks. We can still offer incremental marking in
such cases using regular tasks and without assuming an empty stack.
(cppgc's default platform e.g. doesn't support non-nested tasks.)
This CL also updates GCInvoker to not trigger an incremental GC if we
won't be able to finalize it. That makes finalizing through an
non-nested incremental task safe.
Bug: chromium:1056170
Change-Id: I85f0c9f2efe643cb87dd65d80417eea0d6ee5d52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414217
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69971}
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}
This is a reland of 0ba115e6a9
Changes compared to last reland:
- Fix Python code trying to write to expected_outcomes, which is now a
computed property.
- Fix remaining place in d8.cc that ignored the --fuzzing flag.
- Expect flag contradictions for --cache in code_serializer variant.
Original change's description:
> Reland^3 "[flags] warn about contradictory flags"
>
> Changes:
> - Also allow second parameter influenced by --cache to be reassigned.
> - Fix --stress-opt to only --always-opt in the last iteration as before.
>
> Original change's description:
> > Reland^2 "[flags] warn about contradictory flags"
> >
> > This is a reland of d8f8a7e210
> > Change compared to last reland:
> > - Do not check for d8 flag contradictions in the presence of --fuzzing
> > - Allow identical re-declaration of --cache=*
> >
> > Original change's description:
> > > Reland "[flags] warn about contradictory flags"
> > >
> > > This is a reland of b8f9166664
> > > Difference to previous CL: Additional functionality to specify
> > > incompatible flags based on GN variables and extra-flags, used
> > > to fix the issues that came up on the waterfall.
> > >
> > > This also changes the rules regarding repeated flags: While
> > > explicitly repeated flags are allowed for boolean values as long
> > > as they are identical, repeated flags or explicit flags in the
> > > presence of an active implication are disallowed for non-boolean
> > > flags. The latter simplifies specifying conflict rules in
> > > variants.py. Otherwise a rule like
> > >
> > > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> > > "--gc-interval=*": ["--gc-interval=*"],
> > > }
> > >
> > > wouldn't work because specifying the same GC interval twice
> > > wouldn't actually count as a conflict. This was an issue with
> > > test/mjsunit/wasm/gc-buffer.js, which specifies
> > > --gc-interval=500 exactly like the extra flag by the stress bot.
> > >
> > > Also, this now expands contradictory flags checking to d8 flags
> > > for consistency.
> > >
> > > Original change's description:
> > > > [flags] warn about contradictory flags
> > > >
> > > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> > > >
> > > > Bug: v8:10577
> > > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#68168}
> > >
> > > Bug: v8:10577
> > > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#68989}
> >
> > Bug: v8:10577
> > Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#69339}
>
> Bug: v8:10577
> 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: I4a69dc57a102782cb453144323e3752ac8278624
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352770
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69433}
Change-Id: Ib6d2aeb495210f581ac671221c265df58e8e5e70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398640
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69954}
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}
This commit adds support for capture groups (as in e.g. /x(123|abc)y/)
in the experimental regexp engine. Now every InterpreterThread owns a
register array containing (sub)match boundaries. There is a new
instruction to record the current input index in some register.
Submatches in quantifier bodies should be reported only if they occur
during the last repetition. Thus we reset those registers before
attempting to match the body of a quantifier. This is implemented with
another new instruction.
Because of concerns for the growing sizeof the NfaInterpreter object
(which is allocated on the stack), this commit replaces the
`SmallVector` members of the NfaInterpreter with zone-allocated arrays.
Register arrays, which for a fixed regexp are all the same size, are
allocated with a RecyclingZoneAllocator for cheap memory reclamation via
a linked list of equally-sized free blocks.
Possible optimizations for management of register array memory:
1. If there are few register per thread, then it is likely faster to
store them inline in the InterpreterThread struct.
2. re2 implements copy-on-write: InterpreterThreads can share the same
register array. If a thread attempts to write to shared register
array, the register array is cloned first.
3. The register at index 1 contains the end of the match; this is only
written to right before an ACCEPT statement. We could make ACCEPT
equivalent to what's currently CAPTURE 1 followed by ACCEPT. We
could then save the memory for register 1 for threads that haven't
finished yet. This is particularly interesting if now optimization 1
kicks in.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: I2c0503206ce331e13ac9912945bb66736d740197
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390770
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69929}
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}
Those functions will return a BigInt, which we need to convert to int to
match the value returned by the interpreter.
R=ahaas@chromium.org
Bug: chromium:1127717
Change-Id: I328660ab73776de2bd90b19d18e46663efe6b6cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412177
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69922}
The API in the wasm module builder changed recently
(https://crrev.com/c/2390144). The fuzzer was still emitting code for
the old API.
This CL fixes this for primitive types, and adds a TODO to implement
heap types when needed.
R=ahaas@chromium.orgCC=manoskouk@chromium.org
Bug: chromium:1127717
Change-Id: I514b6e53d0492e5706a5b06d24026da13c3a2165
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412176
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69921}
Currently, the generic wrapper is used for i32 and i64 params and 0 or 1
i32 and i64 return value.
Bug: v8:10701
Change-Id: I4b592d7e0e4ebcb3455520c094c92bf4177c5a5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412179
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#69920}
Check that a v128 imported global in a Wasm module is initialized with a
WebAssembly.Global object.
This is technically impossible, because creating WebAssembly.Global of
type v128 is an error, and creating one of any other type is a type
mismatch. However, we still need this check to avoid hitting an
unreachable case when setting the value of the global later on.
Also, this is not a validation error, since the v128 restriction is only
a Web/JS limitation. Other embedders can choose to do something
different with this module with an imported v128 global.
Bug: chromium:1127740
Change-Id: I6d444578c082b6b1c353cfa2fd82bb42eb14fc3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410659
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69919}
Global.set requires a write barrier. This write barrier was missing in
the original CL. The reland only adds the write barrier for ia32, and
bails out on the other platforms.
Original message:
With this CL we add support for all externref globals except for
imported mutable globals.
R=thibaudm@chromium.org, ulan@chromium.org
Bug: v8:7581
Change-Id: I86328a17200d1edc505f4c4357bdf795d95cf0c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404777
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69912}
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}
The test now verifies that JavaScript programs can be executed
over the REPRL interface, that runtime exceptions can be detected,
and that the engine's state is properly reset between executions.
Change-Id: Ic8032c07e222307cbb4d332e7eaec61936a10ccd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2396082
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Samuel Groß <saelo@google.com>
Cr-Commit-Position: refs/heads/master@{#69883}
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}
JSInliningHeuristic::Finalize did not take into account that by the
time it gets called some of the candidate nodes may have changed to
non-call operators.
Bug: chromium:1127319
Change-Id: I180ed36de98455be6b55790ba7bdb4391ff5fd5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2409273
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69874}
Changes:
- Add optional WasmModuleObject field to WasmGlobalObject
- Introduce DynamicTypeCheckRef. Use it to typecheck imported global
objects.
- Correctly typecheck imported WasmGlobalObjects.
- Add some testing infrastructure and one test file
Bug: v8:7748
Change-Id: Icc62d378d17696c5808d580f1ec84186c9556ec1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2403248
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69872}
This skips the top outliers in debug mode and marks other tests as
slow that frequently flakily time out, see bug.
No=Try: true
Bug: v8:10909
Change-Id: I26b22cceba4a93496f340fe25af0685391fa762b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2407897
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69865}
Stress configurations cause maps to be GC'ed too early.
We now keep them alive by storing the object in a global variable.
Bug: v8:10892
Change-Id: If03c42612d9907b3b6d0df8bb2de879857a89e0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404774
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69862}
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}
