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}
... 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}
Currently, the generic wrapper is used for i32 and i64 params and 0 or 1
i32 return value.
Bug: v8:10701
Change-Id: I8c47e78fa9beeda01bdb647e1fcf9ebe6baf1ee4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2403243
Commit-Queue: Eva Herencsárová <evih@google.com>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69849}
We used to store MinimorphicPropertyAccessInfo indexed on the feedback
slot id. This works fine when there is no inlining but returns the
wrong access information when functions are inlined. Index it
based on FeedbackSource to avoid these problems.
Bug: v8:10582,chromium:1125871
Change-Id: Id01010f3153f7e21495d73899a8604a64417ae95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2401426
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69845}
The commit updates the way the usage is printed for cctest to make use
of HelpOptions which allows the usage string to be passed into
SetFlagsFromCommandLine function.
Change-Id: I8dcd48ca8bb7b025f77c0f05ab37ce4f7b6fae04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2402032
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69839}
- serializer-*:
In some stress configuration, the new map of x was GC'd at the beginning
of optimization, thus generating a soft-deopt for the store to x (thus
in turn skipping inlining of f).
- native-context-*:
In some stress configuration, f had its feedback flushed.
Bug: v8:10892
Change-Id: Icd9f9c0ba6feb938ae8c3b0031b02b766f2e3f91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404764
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69837}
Fix lowering of functions that returns the result of an
i8x16 or i16x8 operation.
Bug: v8:10507
Change-Id: Ia3b29e69cff7771f85dc5160937cbaf2bbc12b55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2399049
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69832}
This is a reland of f25cb50a2f
Removed the problematic tests.
The problem with the test was that we try to pop from an empty segment.
GCC flags that as accessing beyond the array (i.e. index is uint16_t
equivalent of -1). Preceding the actual pop is a DCHECK that asserts
the segment isn't empty. In practice, since we have the DCHECK and
access to the segment is always via a Local, this shouldn't be a
problem.
Unfortunately, GCC flags the access regardless. The DCHECK goes through
a function pointer so GCC cannot determine that in our unittest the
DCHECK would crash if index is 0 and the access would not happen (The
indirection was added to allow for test DCHECK handlers that don't
crash, so we can't mark the function pointer as noreturn).
Drive-by: Segment::Pop and Segment::Push rely on the their Local
counterparts checking of emptiness/fullness, so we should always
access segments via Locals. Making the Segment ctor private.
Original change's description:
> Reland "cppgc, heap: Don't eagerly allocate worklist segments"
>
> This is a reland of c99147c65e
>
> Original change's description:
> > cppgc, heap: Don't eagerly allocate worklist segments
> >
> > Bug: chromium:1056170
> > Change-Id: I75a6b5f52bfe8dd71abc086e5d1e060759ad7fc0
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391254
> > Commit-Queue: Omer Katz <omerkatz@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#69778}
>
> Bug: chromium:1056170
> Change-Id: I4633da065976a6b2710d2f23b946fd2af0e65c83
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2401425
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69806}
Bug: chromium:1056170
Change-Id: I7a122d1a2d20cd4e7c824d249975b4d3df30e03e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2403251
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69829}
Add a bunch of lowering for I64x2 operations. This allows us to enable
most of the I64x2 tests in test-run-wasm-simd.cc.
Most of these lowering are straightforward. The load splat and load
extends need an additional operation to convert the loaded Word32 nodes
to Word64.
Bug: v8:10507
Change-Id: I6c948918c03904d2b6778223a95bb2e34b692a5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2401954
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69827}
Tests failed from time-to-time with --stress-concurrent-allocation. So
run those tests with that flag disabled.
Bug: v8:10315
Change-Id: I8a2b9f03d7bcd8a797134510f608dffb78dd1cdf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2403257
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69826}
This is a reland of 6798619a69
Original change's description:
> [d8] Add d8 global variable
>
> - Add a a "d8" global variable where d8 can provide helpers.
> This in in preparation of adding d8.log for testing our log parsers
> written in JavaScript.
>
> - Separate d8 helper creation into individual functions.
>
> Bug: v8:1064
> Change-Id: I84e434452463afb93ae403f890d8841b20b00703
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400990
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69801}
TBR=verwaest@chromium.org
Bug: v8:1064
Change-Id: I656d550b5ec87dc52dbe6cbbdddf7151ce25031f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2403247
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69819}
This reverts commit e8976cf93a.
Reason for revert: Mark f32x4_cmp as fail, lowering is not fully implemented yet.
Original change's description:
> Revert "[wasm-simd] Stage SIMD"
>
> This reverts commit 1d2726dd0b.
>
> Reason for revert: ODROID failure: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/15814?
>
> Original change's description:
> > [wasm-simd] Stage SIMD
> >
> > SIMD has been pretty stable for a while now, we are not expecting big
> > changes (like opcode renumbers), there might be new instructions added,
> > and they will all be backwards-compatible.
> >
> > The reference interpreter in the SIMD proposal is now capable of
> > generating JS files for all test cases, so we can now run them.
> >
> > There is a bit of tweaking necessary, since SIMD tests are in
> > tests/core/simd subfolder in the spec, so we need to change the glob
> > into a find that will traverse into subdirectory.
> >
> > Bug: v8:10835
> > Change-Id: I1f7e3cf37f21b2aa2537d1e34242da2373bbf626
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2378587
> > Commit-Queue: Zhi An Ng <zhin@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#69793}
>
> TBR=bbudge@chromium.org,ahaas@chromium.org,zhin@chromium.org
>
> Change-Id: I3a90c616109ca048691d97ab45698bc15a678e18
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:10835
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2402379
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69794}
TBR=bbudge@chromium.org,ahaas@chromium.org,zhin@chromium.org,syg@chromium.org
# Not skipping CQ checks because this is a reland.
Bug: v8:10835
Change-Id: I3d87dd2adba6ada2ec3ebf5e13bff378a74b03e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2402386
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69817}
This reverts https://chromium-review.googlesource.com/c/v8/v8/+/2372545
in favour of different solution. In order to simulate filling up a page,
it's not suitable to look at the limit() since there might be observers
that have lowered it, so the page will not actually be full.
Instead, let's relax the CHECK() in CreatePadding() to not look at the
limit() but all available space.
For instance, the test-heap/Regress978156 cctest uses FillCurrentPage()
to fill the current page. However if there's an observer on the current
page, it will not be filled entirely and the test will fail. This works
because by default, when the new space is empty, the scavenger observer
happens to be on the second page of the space. However if one changes
the V8 page size to 512k, then it fails.
This can be reproduced as such:
# Make sure the scavenge trigger is on the first page.
./cctest test-heap/Regress978156 --scavenge-task-trigger=10
# Stress marking adds random observers to trigger incremental
# marking.
./cctest test-heap/Regress978156 --stress-marking=100
This issue also causes crashes when using the %SimulateNewspaceFull()
runtime test function, as found by fuzzing and you can find more details
in the bug.
Bug: v8:10808, v8:9906, chromium:1122848
Change-Id: Ie043ae0a1d3754d2423cb5d97f2b3e1ee860e5c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2401427
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#69805}
My last CL introduced a null-pointer bug there.
Bug: chromium:1126771, v8:7790
Change-Id: Ib16317dea14c9fbad7951cb28ce7bb8bb9ce41c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2402037
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69799}
This reverts commit 1d2726dd0b.
Reason for revert: ODROID failure: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/15814?
Original change's description:
> [wasm-simd] Stage SIMD
>
> SIMD has been pretty stable for a while now, we are not expecting big
> changes (like opcode renumbers), there might be new instructions added,
> and they will all be backwards-compatible.
>
> The reference interpreter in the SIMD proposal is now capable of
> generating JS files for all test cases, so we can now run them.
>
> There is a bit of tweaking necessary, since SIMD tests are in
> tests/core/simd subfolder in the spec, so we need to change the glob
> into a find that will traverse into subdirectory.
>
> Bug: v8:10835
> Change-Id: I1f7e3cf37f21b2aa2537d1e34242da2373bbf626
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2378587
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69793}
TBR=bbudge@chromium.org,ahaas@chromium.org,zhin@chromium.org
Change-Id: I3a90c616109ca048691d97ab45698bc15a678e18
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10835
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2402379
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69794}
SIMD has been pretty stable for a while now, we are not expecting big
changes (like opcode renumbers), there might be new instructions added,
and they will all be backwards-compatible.
The reference interpreter in the SIMD proposal is now capable of
generating JS files for all test cases, so we can now run them.
There is a bit of tweaking necessary, since SIMD tests are in
tests/core/simd subfolder in the spec, so we need to change the glob
into a find that will traverse into subdirectory.
Bug: v8:10835
Change-Id: I1f7e3cf37f21b2aa2537d1e34242da2373bbf626
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2378587
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69793}
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}
Instead of using SKIP (which would skip the tests), we can use
[PASS, FAIL] which signals to run the tests and accept if they are
flakily passing. In this way, we would get coverage and an error if we
have a non-flaky failure.
Bug: v8:10876
Change-Id: Idbdf9dcb76775cf5e81dc1c3bc6d9abb1db23ced
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2401424
Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69790}
Using the Template::Set method which const char name is more ergonomic
and it creates directly an internalized name instead of the normal
string that most users pass in.
Bug: v8:10884
Change-Id: I00c6d49fee9de16b8ebbfe75be4b383831f0d4dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400980
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69787}
The emitted safepoint entries had the wrong size, because it did not
contain StandardFrameConstants::kFixedFrameSizeAboveFp. The code still
worked because the indices of encoded in the entries where too low by
StandardFrameConstants::kFixedFrameSizeAboveFp and thereby corrected
the invalid size. It worked as follows:
First the stack_slots_size gets calculated from the safepoint entry.
Then the position of a stack slot was
"frame_header_base + stack_slots_size - index * pointer_size", where
"index" is what is encoded in the safepoint map. Because of the incorrect
encoding, both stack_slot_size and index were too low by
StandardFrameConstants::kFixedFrameSizeAboveFp. Therefore the errors in
both values eliminated each other, making the end result correct.
With --print-code, the safepoint entry size was also read, and it
crashed because the encoded value was too low.
The reland fixes the indices.
Original message:
With this CL we emit safepoint maps for externref values on the Liftoff
value stack. With that there is support for externref parameters and
locals in Liftoff, as well as for intermediate values of type
externref.
R=thibaudm@chromium.org
Bug: v8:7581
Change-Id: I88444e57745d7b9fe8f1630e904d49736fa9d720
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398531
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69786}
This is a reland of 1c7618abad
The revert was due to an missing dependency in the incremental build,
fixed in https://crrev.com/c/2400987.
Original change's description:
> [serializer] Remove new space
>
> The new space is unused in the snapshot, as we convert all new objects
> to old space objects when serializing. This means we can get rid of
> the snapshot new space entirely, and as a result get rid of the write
> barrier checks.
>
> This also rejiggles the order of the general spaces enum so that the new
> spaces are at the end, and can be truncated off for the SnapshotSpace
> enum.
>
> As a drive by, fix a bug in an unrelated test-api test which this patch
> exposed.
>
> Change-Id: If67ff8be5bf03104a3ffae7df707c22460bba3a1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390762
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69761}
Tbr: jgruber@chromium.org,dinfuehr@chromium.org
Change-Id: I9fbc61a124fae09d12d6281baaca60eb6c39a6e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2401420
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69785}
Adds a field that can be propagated by embedders. The field holds
the detachedness state of DOM objects but can be used in general
by embedder to indicate which objects are for sure part of interesting
application logic and which objects are not. This field is then
processed properly by the DevTools front end.
Bug: chromium:1110816
Change-Id: I53a172208cd69ce2ba2ed9524d36b6512aae7d30
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332174
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69780}
See crrev.com/c/2383030
PerformCheckCast<Data>() itself should not invoke Data::Cast(), since
there is no such method and every publicly available value can be
casted to it anyway. This is an issue in e.g.
GetDataFromSnapshotOnce<Data>().
Change-Id: I4acbff86ffd4537b744dafc588733428e792b4bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2399052
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Gus Caplan <snek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69771}
This is a reland of 95aa697b2f
Original change's description:
> [test][d8] Add d8.log.getAndStop helper
>
> The new helper function allows us to write tests for log parsing
> without the need to first generating a log file. This makes it easier
> to spot errors when the log format changes.
>
> - Add d8 global variable
> - Add file_name accessor to Logger and Log classes
> - Change OS::LogFileOpenMode to w+ / wb+
> - Use separate Log::WriteLogHeader method
> - Remove unused logger_ instance variable from Log
>
> Bug: v8:10644
> Change-Id: Ifc7e35aa4e91b3f01f0847843263946e085944c3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387563
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69715}
Bug: v8:10644
TBR=verwaest@chromium.org
Change-Id: I54741344834d88a376b74e2e3a2047e880a94624
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2396081
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69769}
This CL migrates cppgc to use Ulan's new worklist implementation.
Since there is no central segments array anymore, we cannot rely on
getting the same view (now renamed to Local) given the same task id.
To avoid creating many short lived segments (e.g. for write barriers)
marking state now holds local views for all worklists and provides
access to them.
Bug: chromium:1056170
Change-Id: Id19fe1196b79ed251810e91074046998dc2a9177
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390771
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69767}
This reverts commit 1c7618abad.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20shared/10544
Original change's description:
> [serializer] Remove new space
>
> The new space is unused in the snapshot, as we convert all new objects
> to old space objects when serializing. This means we can get rid of
> the snapshot new space entirely, and as a result get rid of the write
> barrier checks.
>
> This also rejiggles the order of the general spaces enum so that the new
> spaces are at the end, and can be truncated off for the SnapshotSpace
> enum.
>
> As a drive by, fix a bug in an unrelated test-api test which this patch
> exposed.
>
> Change-Id: If67ff8be5bf03104a3ffae7df707c22460bba3a1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390762
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69761}
TBR=jgruber@chromium.org,leszeks@chromium.org,dinfuehr@chromium.org
Change-Id: Iaf2362d8cd3a17d8410030aca0dd2250c5a0a7af
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398533
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69762}
The new space is unused in the snapshot, as we convert all new objects
to old space objects when serializing. This means we can get rid of
the snapshot new space entirely, and as a result get rid of the write
barrier checks.
This also rejiggles the order of the general spaces enum so that the new
spaces are at the end, and can be truncated off for the SnapshotSpace
enum.
As a drive by, fix a bug in an unrelated test-api test which this patch
exposed.
Change-Id: If67ff8be5bf03104a3ffae7df707c22460bba3a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390762
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69761}
Previously to this commit only quantifiers of the form /<x>*/, i.e.
arbitrarily often greedy repetition, were implemented. Now a much
larger class is supported, e.g. + and ? and their non-greedy variants.
Because it came up repeatedly during the implementation, the commit also
adds the Label and DeferredLabel classes to patch JMP and FORK target
addresses more easily.
Still not supported are the following quantifiers:
- Possessive quantifiers, where I'm not entirely sure whether they could
be implemented in principle. Re2 doesn't support them.
- Quantifiers with large but finite numbers for min and max numbers of
repetitions, as in e.g. /<x>{9000, 90000}/. These are currently
limited to some small value. This is because the body of such
repetitions is unrolled explicitly, so the size of the bytecode is
linear in the number of repetitions.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: Id04d893252588abb0f80c3cb33cfc707f6601ea0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387575
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69759}
Add in f64x2 opcodes to simd scalar lowering, this allows us to enable
most of the f64x2 test cases with quite little changes - the significant
change is to make sure the comparisons return a Int64 node.
Bug: v8:10507
Change-Id: I8c8920d37c0cd0841dafcdb0310b6340b3c16189
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2399051
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69757}
v128.const was incorrectly always lowered to 4 word32 nodes, regardless
of what the lowered type was set to be.
In the test case, v128.const was consumed by i8x16.eq, so the lowered
typed of v128.const node was set to SimdType::kInt8x16, but it was still
lowered as a SimdType::kInt32x4, and then later crashes when lowering
the comparisons.
Bug: v8:10507
Change-Id: I24f16c94968cd8b6c7cd5d400d1a0046da3d47da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391919
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69755}
This reverts commit 10348e8eb6.
Reason for revert: https://crbug.com/1125951
Original change's description:
> [wasm][liftoff] Emit safepoints for externref values on the stack
>
> With this CL we emit safepoint maps for externref values on the Liftoff
> value stack. With that there is support for externref parameters and
> locals in Liftoff, as well as for intermediate values of type
> externref.
>
> R=thibaudm@chromium.org
>
> Bug: v8:7581
> Change-Id: I2df0a8d00b2da33fe06ff474b039cca4c7be726d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387571
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69725}
TBR=ahaas@chromium.org,thibaudm@chromium.org
Change-Id: I4cdf7fedfc91cd99302d5cb05e242dbb032c5803
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7581
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398529
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69754}
The original Profiler.getRuntimeCallStats implementation retrieved
a bunch of V8 Counters instead of runtime call counters. This
functionality is now available through the new APIs:
enableCounters, disableCounters and getCounters.
The getRuntimeCallStats API now retrieves real V8 Runtime Call Stats.
Change-Id: I702f60a6c43773f5c41b6861be3f9435975c370f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380853
Commit-Queue: Peter Kvitek <kvitekp@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69753}
With this CL we add support for all externref globals except for
imported mutable globals.
R=thibaudm@chromium.org
Bug: v8:7581
Change-Id: I63cb26f8ad6f4b8fc1c276e223c5d45745122ebf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2396086
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69741}
The wasm interpreter is slow on an arm simulator build with asan when
it comes to return calls. An infinite return-call recursion therefore
caused a timeout on ClusterFuzz. With this CL we increase the costs of
return calls, and thereby avoid the timeout.
R=clemensb@chromium.org
Bug: chromium:1124899
Change-Id: If88e060779fbe2569e289e60170cf487dd31d7db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2397615
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69740}
The parameters should be processed and evaluated in an increasing order
(starting with the 1st param).
Before we started with the last (n-th) parameter which was not correct.
Bug: v8:10701, chromium:1124940
Change-Id: I8e0d8b1f0c53832c8f2d09551879c1a4413e1598
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2396085
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@{#69739}
An earlier cl:
https://chromium-review.googlesource.com/c/v8/v8/+/2354810 fixed loading
double fields with dynamic map checks. The fix however didn't update the
expected type information to also expect Smi fields. So, in the later
optimization phases the CheckHeapObject operation was reduced to a NoP
since the expected type was a HeapObject. This cl fixes the bug by
updating the type to Type::Any.
Bug: chromium:1124696, v8:10582
Change-Id: Ic96dd74c97caf8eaf5289d8e8939f6feb1686a57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2396088
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69730}
With this CL we emit safepoint maps for externref values on the Liftoff
value stack. With that there is support for externref parameters and
locals in Liftoff, as well as for intermediate values of type
externref.
R=thibaudm@chromium.org
Bug: v8:7581
Change-Id: I2df0a8d00b2da33fe06ff474b039cca4c7be726d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387571
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69725}
This reverts commit 95aa697b2f.
Reason for revert: breaks under tsan
Original change's description:
> [test][d8] Add d8.log.getAndStop helper
>
> The new helper function allows us to write tests for log parsing
> without the need to first generating a log file. This makes it easier
> to spot errors when the log format changes.
>
> - Add d8 global variable
> - Add file_name accessor to Logger and Log classes
> - Change OS::LogFileOpenMode to w+ / wb+
> - Use separate Log::WriteLogHeader method
> - Remove unused logger_ instance variable from Log
>
> Bug: v8:10644
> Change-Id: Ifc7e35aa4e91b3f01f0847843263946e085944c3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387563
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69715}
TBR=mlippautz@chromium.org,cbruni@chromium.org,gsathya@chromium.org,verwaest@chromium.org
Change-Id: Iad47d2f1e3391cae3c2f8c9e6c904c43925e1671
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10644
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2396080
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69717}
The new helper function allows us to write tests for log parsing
without the need to first generating a log file. This makes it easier
to spot errors when the log format changes.
- Add d8 global variable
- Add file_name accessor to Logger and Log classes
- Change OS::LogFileOpenMode to w+ / wb+
- Use separate Log::WriteLogHeader method
- Remove unused logger_ instance variable from Log
Bug: v8:10644
Change-Id: Ifc7e35aa4e91b3f01f0847843263946e085944c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387563
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69715}
Functions with v128 in their signatures are always lowered to 4 word32.
So if a return happens to be have an input that is a f32x4 operation, we
get a register allocator error because it tries to fit a float into a
general register. To fix that we need to do some checks when lowering
kReturn, and for each input node, if we are returning a v128, and it is
to be lowered into 4 f32 nodes, we bitcast the floats to ints.
Bug: v8:10507
Change-Id: Iea2fdfc4057304ebf0898e6f7091124629c589f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391331
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69705}
Tests do not expect concurrent allocation and are simply skipped in that
configuration.
Bug: v8:10315
Change-Id: Ia371efa3c27e1f8b76fab47abcce2d7c218224bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390774
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69704}
The generic wrapper can be used for Wasm functions with int32 parameters
and 0 or 1 int32 return values.
Added tests for cases when the return value can & cannot be converted to
a Smi.
Bug: v8:10701
Change-Id: I470954ed0aced0e4ec6e65a9f38caac19c576549
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390141
Commit-Queue: Eva Herencsárová <evih@google.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69700}
There is an int version that will be TNodified in a follow-up CL.
Bug: v8:9708, v8:6949
Change-Id: I3a47cb352396dfe9dea426b6396216c06e0e3254
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387963
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69695}
This is a reland of 9eb090d261
The android-pie-arm64-dbg compiler error was fixed in:
https://chromium-review.googlesource.com/c/v8/v8/+/2381450
Original change's description:
> [heap] Add concurrent typed slot recording
>
> Since the typed slot set is not thread-safe, each concurrent marking
> barrier collects typed slots locally and publishes them to the main
> typed slot set in safepoints.
> Bug: v8:10315
>
> Change-Id: If1f5c5df786df88aac7bc27088afe91a4173c826
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370302
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69576}
Bug: v8:10315
Change-Id: Iae2882bad1cd0ffcae28c96318ba5fd7937f2215
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390763
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69694}
Tests that use SimulateFullSpace and SealCurrentObjects do not work
if there is a background thread allocating concurrently.
Bug: v8:10315
Change-Id: I73a4c9db8eb32fdf3e07fcb8f5dda309de797709
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390765
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69693}
ManualGCScope is used in tests that perform GC manually. Stressing
concurrent allocation interferes with that and may trigger more GCs
than the test expects.
Bug: v8:10315
Change-Id: I6705f0b7cc555074b319a41d29810936b5a2a556
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2392242
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69691}
Due to the way SSE flags work, we need to enable all versions prior to
SSE 4.1 as well.
Bug: v8:10863
Change-Id: I50ddd3f486641e7bf22c651fc2c9a8a4ccbc2b46
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391325
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69687}
With https://crrev.com/c/2389982 we are now forcing the sse flag in this
test, so we no longer need the flag check. Keep it around for the other
archs.
The nosse41 condition will be removed from the test runner in the next
patch.
Bug: v8:10863
Change-Id: I7eacb21803e6cc810384d3e4881d2a965dc1ad69
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391320
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69684}
- JobHandle::IsCompleted()
- JobDelegate::GetTaskId()
- worker_count passed as argument to GetMaxConcurrency().
Jobs implementation must call the new GetMaxConcurrency(), but Jobs
users aren't migrated yet.
Bug: chromium:1114823
Change-Id: Ie09a8847d1cb884b1e388903370e49f33fa25a64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2374308
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69683}
During spread operation, after VisitForAccumulatorValue,
set the position of the current expression again
Bug: chromium:929844
Change-Id: I6e9ca87587789f9cb21e939d4405414c8170b232
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379531
Commit-Queue: HyeockJin Kim <kherootz@gmail.com>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69677}
v8::String::IsExternal is confusing since it only checks for external
two byte strings. The goal is to reintroduce String::IsExternal which
checks for one and two byte external strings after removing the old,
misleading api method.
- Add String::IsExternalTwoByte
- Deprecate String::IsExternal for now since it is misleading
Bug: v8:10641
Change-Id: I8989de7576c823846e0536fc1898e769b6d68c87
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284495
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69674}
Previously we checked whether a thread's pc IsPcProcessed before pushing
to the stack of (postponed) active_threads_. This commit moves the
IsPcProcessed check and corresponding MarkPcProcessed call to when the
thread is actually processed, i.e. when it is popped from the
active_threads_ stack again.
This fixes two issues:
- Consider what used to happen in the following scenario:
1. An active thread t is postponed (e.g. because it is a fork) and
pushed on active_threads_. IsPcProcessed(t.pc) is false, so t is
not discarded and does actually end up on active_threads_.
2. Some other thread s is executed, and at some point s.pc == t.pc,
i.e. t.pc is marked as processed.
3. t is popped from active_threads_ for processing.
In 3 we don't want to continue execution of t: After all, its pc is
already marked as processed. But because previously we only checked
for IsPcProcessed in step 1 before pushing to active_threads_, we used
to continue execution in 3. I don't think this is a correctness
issue, but possibly a performance problem. In any case, this commit
moves the IsPcProcessed check from 1 to 3 and so fixes this.
- After flushing blocked_threads_, we push them to active_threads_
again. While doing so, we used to mark these thread's pcs as processed.
This meant that sometimes a (fork of a) high priority thread was
cancelled by the IsPcProcessed check even though its pc was only
marked as processed by a thread with lower priority during flushing.
We need it to be the other way round: The low priority thread should
be cancelled after its pc is processed by a thread with higher
priority.
With this commit we don't MarkPcProcessed during flushing, it's
postponed to when we're actually processing. This was a correctness
issue, and there's a new corresponding test case.
Bug: v8:10765
Change-Id: Ie12682cf3f8a04222d907edd8a3ad25baa69465a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388112
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69668}
The test is slow and checks the limits of the WebAssembly
implementation. Sanitizers are slower and therefore sometimes run into
timeouts. Therefore we just disable the test for sanitizers.
R=leszeks@chromium.org
Change-Id: I4a0cb994dfc34097849f0dd8528dc158883fbc8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2389980
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69667}
The test is incompatible with --noenable-sse4-1, which is randomly
added by numfuzz (and possibly other fuzzers).
The "Flags" from the test files are always passed last and are often
used to neuter incompatible flags.
Bug: v8:10863
Change-Id: I8fd11b4d38586f25f5af63ab8ef83873dc250557
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2389982
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69665}
This adds the argument count (as intptr) to the standard frame.
StandardFrames are now in the same shape as OptimizedFrames.
The argument count in the stack will be used to tear down the arguments when we remove the arguments adaptor frame.
Change-Id: If9cc2946321bc1bb0abb776521e2d5b683ab0532
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2312783
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69663}
For TypedArray, a fast path is used when using the builtin iterator, and
next method has not been overriden. If we use that fast path for JSArray
too, the method will be about 200x times faster on a large array.
This patch also fixes a bug when a typed array is modified during the
mapper execution. In that case, the modification should not be taken
into account.
Bug: v8:10802
Change-Id: I74e2cbcd6a654def318585b4e08745037584669a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2358749
Commit-Queue: Arnaud Renevier <arenevier@fb.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69655}
The handle was always created empty which resulted in a DCHECK crash
in debug builds and in never-cancelled tasks in release builds.
Bug: chromium:1056170
Change-Id: I798ce65c37738bbe9c60b44b692ff04536f6d830
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388101
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69653}
There were some +/- infs hidden in that list of NaNs (and those were
repeated too). Add a NaN with top bit of payload unset. This will help
catch cases where we did not canonicalize results properly.
Bug: v8:10862
Change-Id: I05e3e0b2351430abf3eaa859a0d828f43b44cfb6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2386483
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69651}
Allows reflection of v8::Data types, such as being able to check if a
value is a v8::Module. This is useful for libraries which wrap the V8
API, such as rusty_v8.
Change-Id: I4841c5f7f60885b20e1504c8562e278844ff7ec3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2382719
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Gus Caplan <snek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69649}
With a recent change, we require WebAssembly code to be tiered up to
serialize it, see https://crrev.com/c/2349290. In that CL tests were
adjusted to set the --wasm-tier-up flag when serialization was involved.
However, the test adjusted in this CL was missing, because this test
used the kExprRefNull instruction, which caused a bailout to TurboFan
anyways. With recent changes, Liftoff can compile kExprRefNull now,
and therefore causes problems.
R=thibaudm@chromium.org
Bug: v8:10852
Change-Id: I9b89f37c22f17cbf046110f3ee1c98bfea73e009
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387574
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69648}
This adds a global counter for the various reasons we might fail to
attribute a tick.
The counters are cleared and printed when Profile::Print() is called,
which we call in our tests, so flaky test output will now contain these
stats along with the printed profile tree.
Drive-by cleanup some print functions and make them const.
Change-Id: Ia3a27405f5b5346adfdbb32afc7e414857969cc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550406
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69647}
The generic wrapper can be used for Wasm functions with int32 parameters
and no return values.
Changed the GC scanning for the generic wrapper.
Added tests for cases when all the parameters of the Wasm function fit
into registers and when some of the parameters are on the top of the
stack.
Change-Id: I511fd04d2a4a2bdc4a6f72d72e2867a03b256f6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381459
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#69645}
The fuzzer function is called multiple times with libfuzzer. Trap
handlers, however, should only be initialized once. With this CL we add
a flag to initialize trap handlers only once.
R=clemensb@chromium.org
Bug: chromium:1122590
Change-Id: Ib51a50cfe9dad5e3133de3085ad147f5a069b1bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384769
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69643}
This reverts commit dfb3f7daa5.
Reason for revert: Breaks LSAN & ASAN flakily: https://bugs.chromium.org/p/v8/issues/detail?id=10861
Original change's description:
> [cpu-profiler] Ensure sampled thread has Isolate lock under Windows
>
> 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 extracting info from a
> heap in motion. 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: Iab2493130b9328430d7e5f5d3cf90ad6d10b1892
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377108
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69623}
TBR=akodat@rocketsoftware.com,petermarshall@chromium.org,petermarshall@google.com
Change-Id: Ib6b6dc4ce109d5aa4e504fa7c9769f5cd95ddd0c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10850
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387570
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69638}
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}
Heap growing estimates when to start incremental gc such that it
will finish when we are expecting to finalize (i.e. when an atomic
gc would be triggered).
There is also a minimum ratio between limit for atomic gc and limit
for incremental gc, to guarantee that incremental gc get's some time to
run even with the application rarely allocates.
This is a continuation of:
https://chromium-review.googlesource.com/c/v8/v8/+/2377691
Bug: chromium:1056170
Change-Id: I8c87e98d60b6f8b5748558771a236f15385f7858
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381454
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69630}
This regression test does not work on MIPS without SIMD since the scalar
lowering is not complete yet. Skip it for now.
Bug: v8:10831
Change-Id: Icc407488a96d4c965c1cf956f7a74abde078d421
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2385855
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69626}
By eager compile all functions in the startup snapshot, the startup
snapshot can contain all function codes without warm-up.
BUG=v8:4836
R=yangguo@chromium.org
Change-Id: I07e86b6940c2fe75816df8ae429d110272216d0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379535
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69624}
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 extracting info from a
heap in motion. 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: Iab2493130b9328430d7e5f5d3cf90ad6d10b1892
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377108
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69623}
This CL adds support for disjunctions and some quantification in
EXPERIMENTAL regexp patterns. It is implemented using a new bytecode
format and an NFA-based breadth-first interpreter.
R=jgruber@chromium.org
Bug: v8:10765
Change-Id: Idd49a3bbc9a9fcc2be80d822c9d84a638e53e777
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370634
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69621}
The graph assembler calls MergeControlToEnd as part of Unreachable
node creation; this causes issues when used inside the GraphReducer
framework, since the reducer is not notified by gasm that the end node
should be revisited.
The (hacky) fix in this CL is to always mark the end node for
revisitation after a gasm reduction has taken place.
Bug: v8:8888,chromium:1123379
Change-Id: I350bb7144add04a0c3fd7f3d88c07fcfe1cd42e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384772
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69619}
The goal is to have one graph per test case, and inside the graph,
4 different lines:
- baseline
- baseline noopt
- super-ic
- super-ic noopt
Bug: v8:9237
Change-Id: I511b5555487a3d96698a3fb648abf76a13f76858
No-Try: True
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384770
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69618}
A recent unrelated change caused these tests to get unlucky in
GC stress mode. Their "assertOptimized" expectations rely on
certain type feedback data not getting flushed at the wrong time.
Bug: v8:10846
Change-Id: I86d0b0c049539e4a69aa764cc6ec92465ca12beb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381458
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69617}
With conservative stack scanning enabled, a snapshot of the call stack
upon entry to GC will be used to determine part of the root-set. When
the collector walks the stack, it looks at each value and determines
whether it could be a potential on-heap object pointer. However, unlike
with Handles, these on-stack pointers aren't guaranteed to point to the
start of the object: the compiler may decide hide these pointers, and
create interior pointers in C++ frames which the GC doesn't know about.
The solution to this is to include an object start bitmap in the header
of each page. Each bit in the bitmap represents a word in the page
payload which is set when an object is allocated. This means that when
the collector finds an arbitrary potential pointer into the page, it can
walk backwards through the bitmap until it finds the relevant object's
base pointer. To prevent the bitmap becoming stale after compaction, it
is rebuilt during object sweeping.
This is experimental, and currently only works with inline allocation
disabled, and single generational collection.
Bug: v8:10614
Change-Id: I28ebd9562f58f335f8b3c2d1189cdf39feaa1f52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375195
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69615}
For SIMD instructions that use aligned moves (like movaps or movapd), we
don't have correct memory alignment for SIMD moves yet. Switch to to
movupd.
Bug: v8:9198
Bug: v8:10831
Change-Id: Ic60fba5d08dda9676f6091ce505ac7be54957d00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380240
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69613}
Even though we provide a --wasm-max-code-space flag (defaulting to
{kMaxWasmCodeMB}, we still had checks in place that the actual committed
code space is not bigger than that constant.
This CL fixes that by always comparing against the value of the flag.
This will allow us to specify a code space limit which is larger than
the default. This is useful when debugging larger Wasm apps which exceed
the limit, but are not meant to be shipped that way.
Drive-by: Remove a dead use of the {kMaxWasmCodeMemory} constant.
R=ecmziegler@chromium.org
Bug: chromium:1117033, chromium:1114093, chromium:1107649, chromium:1111266
Change-Id: I2684446230a8a6f0a27ad963dd6f36e5764b25e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376810
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69611}
Those globals must have type float instead of int to preserve the sign
bit.
R=ahaas@chromium.org
Bug: chromium:1069173
Change-Id: I9769f47f087aaba94a6172118be44f70adeded0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379861
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69609}
This is the first step in a series of CLs. The goal is to make
super property access faster.
Design doc: https://docs.google.com/document/d/1b_wgtExmJDLb8206jpJol-g4vJAxPs1XjEx95hwRboI/edit?usp=sharing
This CL:
- Add bytecode LdaNamedPropertyFromSuper
- IGNITION_HANDLER just calls Runtime::LoadFromSuper
- JSGenericLowering::LowerJSLoadNamedFromSuper just replaces the node
with a runtime call to Runtime::LoadFromSuper
Bug: v8:9237
Change-Id: Id28e935294c5068dd6c54e6b860a77d61517fff5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2327912
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69604}
Explicit nullification aims to simplify migration to Oilpan, in the
case when unique_ptrs are converted to Member and user code relies on
source pointers to be in "empty" state.
Change-Id: Ia54137d53ca03f93932b3c1f2eaba439a416a06e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379857
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69603}
Schedule is simpler compared to the schedule in blink since it now
returns deadlines based on marked bytes instead of time.
If marking is ahead of schedule, return the minimum step size.
Otherwise, set step size to catch up to schedule (ignoring the time
passed while performing the step).
No more default initial step size (needed in blink since marking speed
was unknown).
If estimated schedule is exceeded (marking takes longer than 500ms), the
steps will try to mark all remaining objects but would still be capped
by the maximum step duration of 2ms.
Bug: chromium:1056170
Change-Id: I09857db161c621a12d064f9c8c21b646c34f9d71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375200
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69602}
Starting marking required Creating a Marker and calling StartMarking.
StartMarking should always have been called immediately after creating
the marker.
Since markers are not persisted between GC (a marker exists only while
marking is in progress), it makes sense to start marking implicitly when
a marker is created.
Calling StartMarking in MarkerBase ctor is inadvisable since subclasses
might still to initialize fields.
Using MarkerFactory instead guarantees that StartMarking is always
called immediately after creating a Marker.
Bug: chromium:1056170
Change-Id: Icbf11afd848e1618c204ca6bf951600b3ae9fef2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375199
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69601}
This reverts commit 9eb090d261.
Reason for revert: breaks trybot android-pie-arm64-dbg, repro steps: build cctest with target_cpu="arm64" in the args.
See thread:
https://chromium.slack.com/archives/CGJ5WKRUH/p1598563610118900
Original change's description:
> [heap] Add concurrent typed slot recording
>
> Since the typed slot set is not thread-safe, each concurrent marking
> barrier collects typed slots locally and publishes them to the main
> typed slot set in safepoints.
> Bug: v8:10315
>
> Change-Id: If1f5c5df786df88aac7bc27088afe91a4173c826
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370302
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69576}
TBR=ulan@chromium.org,dinfuehr@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:10315
Change-Id: Iade0443e5eccef06e3ea77913e18fd1f563995f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380613
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69597}
Move fractionalSecondsDigits between second and timeZoneName
Change order of reading options.
To sync with the July 20 PR change in
ba085a9111
Latest ECMA402 PR https://github.com/tc39/ecma402/pull/347
Bug: v8:10836
Change-Id: Ia414e0c7cc18502ccabaf02abd19861410b87cae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2378460
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69591}
In order to improve our tiering strategy, it is a good idea to start
by tiering up functions that will be used the most, as this is done in
most JavaScript engines.
To decide which function requires tiering, we use as a basic strategy
to define its compilation priority to 'func_size * number_of_calls',
this roughly approximates the time we spend in the function.
To handle prioritization, it seemed that using a concurrent
priority queue similar to BigUnits was causing concurrencies issues.
I then decided to use different priority queues for each worker thread.
R=clemensb@chromium.orgCC=thibaudm@chromium.org
Bug: v8:10728
Change-Id: I6f314468549000b2a9b51d3d470f04a0cb997879
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2367859
Commit-Queue: Arnaud Robin <arobin@google.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69585}
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}
Now that 86 has branched, we can move bitmask into the SIMD MVP, it will
not affect the current OT. (We want any OT extension to include
bitmask.)
Bitmask was accepted into the proposal in
https://github.com/WebAssembly/simd/pull/201.
Bug: v8:10308
Change-Id: Ib61190fcea2bfc0ce7bf733086e1a81388216a59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2378290
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69577}
Since the typed slot set is not thread-safe, each concurrent marking
barrier collects typed slots locally and publishes them to the main
typed slot set in safepoints.
Bug: v8:10315
Change-Id: If1f5c5df786df88aac7bc27088afe91a4173c826
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370302
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69576}
Fix Heap-use-after-free READ 2 in Intl.Segmenter
when the segments got free during the iteration
We need to keep a copy of the string in the iterator instead
of depending on the one referenced from the segments.
Bug: chromium:1121156, v8:6891
Change-Id: I26ef5baccaa470dc1bd8cc229c737f556d27160e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376173
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69575}
The fuzzers were calling the compiled function without passing explicit
arguments. Thus all arguments were converted from the "undefined" value,
which typically results in a zero value, as expected.
For BigInt though, it's not allowed to pass "undefined". We have to pass
a proper BigInt.
This CL implements this by passing explicit parameter values for all
parameters.
This effectively unlocks testing BigInt parameters in all fuzzers, thus
may increase coverage and find new bugs.
R=ahaas@chromium.org
Bug: chromium:1120355
Change-Id: I4e451d2418eb73d460fa937d1cf95a1ab6c99cf5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377945
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69570}
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}
Some shuffles take have either register or memory operand for second
input, but the codegen incorrectly assumes that it is always a register.
Bug: v8:10824
Change-Id: Ia2df233dad4ed451e52e57e35cce5c80db0905db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2373586
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69562}
This is a reland of c2ea20473d
Original change's description:
> [wasm] Move kMaxWasmCodeSpaceSize to wasm directory
>
> This limit is wasm-internal, and does not need to be exposed via
> src/common/globals.h.
> This CL moves it into the {WasmCodeAllocator}.
>
> Drive-by: Minor simplification in jump table stress test.
>
> R=ecmziegler@chromium.org
>
> Change-Id: Iff8c4657697ae98123d840a022c5b21c4948fcdf
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375189
> Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69558}
Change-Id: I6e0432d14d23978dea599233e620e84d8255caf9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375388
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69560}
This reverts commit c2ea20473d.
Reason for revert: Link failures: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20cfi/26209
Original change's description:
> [wasm] Move kMaxWasmCodeSpaceSize to wasm directory
>
> This limit is wasm-internal, and does not need to be exposed via
> src/common/globals.h.
> This CL moves it into the {WasmCodeAllocator}.
>
> Drive-by: Minor simplification in jump table stress test.
>
> R=ecmziegler@chromium.org
>
> Change-Id: Iff8c4657697ae98123d840a022c5b21c4948fcdf
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375189
> Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69558}
TBR=clemensb@chromium.org,ecmziegler@chromium.org
Change-Id: Ic3466eb17f2b3dfa4a0864002b0590fa0f571bb5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375387
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69559}
This limit is wasm-internal, and does not need to be exposed via
src/common/globals.h.
This CL moves it into the {WasmCodeAllocator}.
Drive-by: Minor simplification in jump table stress test.
R=ecmziegler@chromium.org
Change-Id: Iff8c4657697ae98123d840a022c5b21c4948fcdf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375189
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69558}
While LocalHeap allow to dereference handles on background threads, this
is only possible when FLAG_local_heaps is enabled.
Bug: v8:10315
Change-Id: Ia27582cda7e4b4faf4d2c76959de418415e1ae68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2372147
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69557}
This CL is the start to implement reference types support in Liftoff.
As a first step this CL implements the ref.null instruction, and allows
reference types as return values. This allows register allocation to be
extended to support reference types, and also adds an easy way to get a
reference type value for tests. Additionally with ref.null we don't have
to worry about garbage collection because 'null' is an immovable object
and therefore does not have to be scanned by the GC.
R=thibaudm@chromium.org
Bug: v8:7581
Change-Id: I5785dcf522c0d9881e1386f2d8b5d8560a16225c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352784
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69556}
- JobHandle::IsCompleted()
- JobDelegate::GetTaskId()
- worker_count passed as argument to GetMaxConcurrency().
Jobs implementation must call the new GetMaxConcurrency(), but Jobs
users aren't migrated yet.
Bug: chromium:1114823
Change-Id: I0f4295ccaf9eba866dd771f30e2e49aa3eae9551
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352484
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69553}
The cctests need to simulate full pages, however the calculation of the
remainging available space is wrong causing an assertion when we change
the V8 page size to 512K:
$ cctest test-array-buffer-tracker/ArrayBuffer_PagePromotion
#
# Fatal error in ../../test/cctest/heap/heap-utils.cc, line 94
# Check failed: padding_size <= overall_free_memory || overall_free_memory == 0.
The reason is:
- On startup, we register a scavenger observer on the new space. The
observer is set to trigger when the new space capacity is at 80% by
default.
- On linux, the initial capacity of the new space is 512K, so the
scavenger observer will be placed at 80% of 512K, which will either
be in the second page of the space if the page size is 256K, or in
the first page if the page size is 512K.
- When placing the observer, if the observer hits the first page, we
lower the allocation limit (see `ComputeLimit()`). This makes sure
the observer isn't skipped by allocations inlined in generated code.
However, when we simulate filling the current page, we compute the space
left in the current page by comparing the top with the `page_high()`
rather than `limit()`. This was done so the tests would also work when
inlined allocations are disabled. If we don't look at the `limit()`, we
don't take the observer into account and fill more space than is
available, triggering the assertion.
This can also be reproduced by reducing the % at which the scavenger is
triggered so that it hits the first page instead of the second when the
page size is 256K, for example passing --scavenge-task-trigger=10.
Bug v8:10808, v8:9906
Change-Id: Iad50bb68995de5ee017dcbe069d1fb229c9f5985
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2372545
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69550}
With in-place representation changes we can transition from a double
field to a Tagged field without changing the map. So it is not always
safe to assume the loaded value would be a HeapNumber. TurboFan takes a
dependency on the field representation to ensure the code is deoptimized
on any changes. With dynamic map checks, it is not possible to take such
a dependency. Hence check the loaded value is a HeapNumber and
deoptimize otherwise.
Bug: chromium:1112155,v8:10582
Change-Id: I910ac1c0781ac8842fdbf272f9173b55b02923ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354810
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69521}
This is a reland of 1dd7f3a953
Original change's description:
> [heap] Add concurrent marking write barrier
>
> A LocalHeap creates and owns an instance of MarkingBarrier. A pointer to
> the marking barrier is set to a thread_local variable for a quick access.
>
> WriteBarrier::MarkingSlow fetches the thread_local variable and invokes
> the write barrier if it is set. Otherwise, it invokes the main thread
> heap()->marking_barrier().
>
> Each marking barrier has its own local marking worklist that is
> published during scavenge (for updating pointers) and at finalization
> of incremental marking.
>
> Typed-slot recording does not work yet because it is not thread-safe.
> It will be fixed in a subsequent CL.
>
> Bug: v8:10315
> Change-Id: I221a906436cd91e7405a253ce0eb06cf68046f2c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354809
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69448}
Bug: v8:10315
Change-Id: I155bb0aadd53a5333672fb085b33d8da86f3f336
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364509
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69517}
Some tests are failing now and have been marked as failing to
investigate them.
R=jkummerow@chromium.org
Change-Id: I1242ccf3bdc8f4d2ff55bc016c43fa51c556376e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2366696
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69513}
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}
This CL adds a bytes based deadline to draining of worklist.
The time based deadline is also kept because:
1) Unified heap can't transition to bytes-based deadlines yet.
2) Unified heap with concurrent marking needs to flush v8 references
which don't count as marked_bytes and can cause very long incremental
pauses.
Bug: chromium:1056170
Change-Id: I5ab57754e7ff0b5821f3acb76e1e6f59fc9d68b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299374
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69506}
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}
On x64, trap handlers are enabled as part of the default configuration.
However, each embedder has to enable trap handlers explicitly, and in
the wasm fuzzers, trap handlers were not enabled. This CL enables trap
handlers now in all wasm fuzzers.
Drive-by change: enable all staged wasm features in the wasm-async
fuzzer.
R=clemensb@chromium.org
Change-Id: Ib7c2addb092551b5554a2b74830e5b67db077909
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362957
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69500}
Load extends always load 8 bytes, so the access size does not depend on
MachineType of the load. The MachineType is used for classifying the
lane shape of the 8-byte load.
Also add cctest to load splats and load extends to test OOB. (Note that
load splats access size depends on MachineType).
Add regression test from clusterfuzz, minimized by ahaas@. Remove the
`--no-wasm-trap-handler` flag since we have a no_wasm_traps variant that
should test this flag.
Bug: chromium:1116019
Change-Id: I27ba051d0536ca0f6fd75dd641ca9b78132dafed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2363291
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69489}
This CL adds a basic implementation of incremental marking for standalone GC.
Followup CLs include:
* Use bytes instead of time as deadline
* Port incremental marking schedule from blink
* Mark on allocation
* Guarantees for progres/termination for standalone GC
* etc...
Calling StartIncrementalGarbageCollection triggers StartMarking which
schedules incremental marking as non-nestable tasks.
For unified heap, marking will continue running until it runs out of
work but it won't finalize independently.
For standalone, when incremental runs out of work it will schedule a new
task in which it will finalize marking and trigger the rest of the GC.
Users of standalone can also force finalization before incremental
marking as finished using FinalizeIncrementalGarbageCollectionIfRunning.
Calling CollectGarbage would also finalize an on-going incremental GC
if one exists. Otherwise it will trigger an atomic GC.
See the following doc for explanation of the various methods:
https://docs.google.com/document/d/1ZhJY2fOoD8sH53ZxMh2927Zl8sXqA7azJgcQTWx-YKs/edit?usp=sharing
Bug: chromium:1056170
Change-Id: I75ead414eb9da9f8b7f71c4638b9830fce7708ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2298009
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69480}
When CFI is enabled this adds a check against this list whenever a new
return address must be set in a deoptimized frame, as a mitigation for
ROP attacks.
The list is known at linking time so that its content and the pointer
to it can be stored in a read-only memory section.
The check is performed in the signing function, which is no longer
generic, as well as when setting the current pc of the frame.
Since the pc is now only signed when setting the caller's pc, there
is no need for ReplaceContext anymore.
Bug: v8:10026
Change-Id: I5e85a62b94722051716fdeba476db383c702a318
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287490
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Rodolph Perfetta <rodolph.perfetta@arm.com>
Cr-Commit-Position: refs/heads/master@{#69478}
... to avoid the repeated pattern of calculating it.
Bug: v8:8888
Change-Id: I4af5264aae6cfb8b6232b5aaf9ceb2cb568c29d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362692
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69469}
The V8 wasm fuzzer can create regression tests for failing fuzzer cases.
These regression tests use the wasm-module-builder.js. With the addition
of simd to the wasm-compile-fuzzer, the fuzzer can now create test cases
that use simd instructions, but the wasm-module-builder.js did not know
yet about the new instructions. This CL adds some instructions to
wasm-module-builder.js.
R=zhin@chromium.org
Bug: chromium:1116019
Change-Id: I198e4f11c2225a65d6b438f95e351fc14ee66218
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362694
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69467}
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}
There exists such optimization for additions but not for multiplication.
This adds optimizations that apply the reductions
(x * Int32Constant(a)) * Int32Constant(b)) => x * Int32Constant(a * b)
(x * Int64Constant(a)) * Int64Constant(b)) => x * Int64Constant(a * b)
to the TurboFan graph.
Bug: v8:10305
Change-Id: I28f72c2b7d8ff0f758a0a08b69fb3763557a6241
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2360327
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69462}
