Add a flag for controlling the maximum number of threads usable by the
LazyCompileDispatcher.
Change-Id: I87fc39d337a00cff0c3d152392630f48da050fff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312482
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78214}
Set the JS limit at a 40KB offset from the actual limit, like on the
native stack. This is an estimate of the maximum stack space needed for
runtime calls.
R=ahaas@chromium.org
Bug: v8:12191
Change-Id: I709d5b25c5e47d2474cf4205ebcb8ee7fc8e794c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312485
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78212}
The call to SyncStackLimit is already inlined in the previous runtime
call (WasmAllocateContinuation).
R=ahaas@chromium.org
Bug: v8:12191
Change-Id: Ie602f8317bc9ed5b5b5f9a0eb545a57602aeed42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312484
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78210}
This allows streamed sources to also trigger parallel compile tasks. The
chunk vectors are shared via std::shared_ptr.
Clone chunked streams are initialised with a null source, and are not
allowed to fetch any more data. Similarly, the original stream is not
allowed to fetch data if it has been cloned (since the vector is shared
and would mutate if we added more data to it).
This is ok for the purposes of cloning for parallel compile tasks, as we
fully parse before cloning for the task.
Change-Id: Ic268e4956e0894acb63111bf0aaf32eaad426066
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310917
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78209}
Baseline compiler generates calls to builtin Bitwise_Baseline for
bitwise bytecodes with Smi rhs. The builtin still performs type check
for rhs even though it is known to be Smi.
This CL implements new builtins for bitwise operations which does not do
speculation for rhs.
Bug: v8:12442
Change-Id: Ia6e1b25a74d00db8c39600b4f81f6e9aa5d59253
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310520
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Hao A Xu <hao.a.xu@intel.com>
Cr-Commit-Position: refs/heads/main@{#78206}
... as a prerequisite for adding InstructionStream heap object.
Bug: v8:11880
Change-Id: I22b4832cedd46bee4a4c5a0d7b5032eba10b2a7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310900
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78204}
This CL makes sure to forward the information that we are pausing
because of a debugger statement, and to encode it explicitly
as an 'other' reason when reporting the pause to the front-end.
Drive-by: refactoring the way break reasons are propagated by
introducing a new enum for break reasons
Bug: chromium:1229541, chromium:1133307
Change-Id: I9d2e8d8da54d96a231eff9d1f62b74507955b18f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306978
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78202}
We optimize away type upcasts for nominal types in WasmFullDecoder.
Upcasts trivially hold for nominal types, which is not the case for
structural types. Note that we already optimize away trivially-failing
checks (when types are unrelated) for both nominal and structural types.
Bug: v8:7748
Change-Id: I720c9803cb8b4071aa4bae112ce06d587b7a68fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306984
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78201}
--wasm-speculative-inlining makes no sense if --liftoff-only or
--no-liftoff, since it needs type feedback from Liftoff and is appied
by Turbofan. Therefore, it should be disabled in these cases.
Specifically, --wasm-speculative-inlining implies
--wasm-dynamic-tiering, which contradicts --liftoff-only.
Bug: v8:12166
Change-Id: Idc5e0d7ceb7dbdf82ea6fd14ffc8386fe35a1257
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306554
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78200}
{V8::Dispose} calls {FlagList::ResetAllFlags()}, which resets all flag
values. Thus the values of FLAG_dump_counters and FLAG_dump_counters_nvp
need to be read before disposing v8.
Drive-by: Two unrelated code simplifications / unifications.
R=mlippautz@chromium.org
Bug: chromium:1275117
Change-Id: Ie2bbe0c844efaf3ed50a62533c5ec08b6b423379
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310881
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78199}
This flag is not supported now.
Bug: chromium:1271841
Change-Id: I6a80ebed79a03164f58f1757b8ebaca74a681441
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306786
Auto-Submit: Junji Watanabe <jwata@google.com>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78198}
This fixes operators in wasm Turbofan that were mixing up integer sizes
and pointers with tagged pointers.
Additional changes:
- Remove unused (and non-compiling if V8_MAP_PACKING)
GraphAssembler::StoreMap.
- Factor out WasmGraphBuilder::IsNull.
Change-Id: I9d99827e35507adc0af391bd39975d55371b98cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306981
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78196}
That code should be dead now that we compute the description in Blink
(see crbug.com/1048143).
Bug: chromium:1275591
Change-Id: I6e8c4dec27eb981807ab4eba75572635ee655a3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310837
Auto-Submit: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78195}
This CL removes the CallRefData data structure and accesses a funcref's
target and instance through the funcref.
Bug: v8:7748
Change-Id: Ic46b127f7775052d5df13b03c447e3b15328ad74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306486
Commit-Queue: Richard Stotz <rstz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78194}
Moved DEFINE_UINT after the #ifdef block, so it is also defined
for Mac arm64.
This is a reland of 6aadf0e0ff
Original change's description:
> [baseline] Add max threads flags for CSP
>
> Bug: v8:12054
> Change-Id: I49238fe673858b60c2a2a935ed1f45f465269216
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308707
> Auto-Submit: Victor Gomes <victorgomes@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78187}
Bug: v8:12054
Change-Id: Ica352b2f099fff875411c0e1915bcddb4ca48061
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310800
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78192}
This fixes data races when lazily creating counters (and populating the
{counter_map_}, and when concurrently adding samples to the counters.
It also ensures that the Wasm engine is stopped (via {V8::Dispose})
before printing and deleting counters, as background threads might still
try to update the counters otherwise.
R=mlippautz@chromium.org
CC=nikolaos@chromium.org
Bug: v8:12453, chromium:1275117
Change-Id: Ie6beea6cc74eea52143d12f9921597da4a250f2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308710
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78191}
The new flags enum had kReduceMemory as the first value, which means it
got the value 0 and thus was considered as never set.
Bug: v8:12407, chromium:1274954
Change-Id: Ifcce2316c1dcd09a12ad52ef391f513b014aea1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310609
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78189}
When emitting code, character ranges must only specify ranges which
the actual subject string (one- or two-byte) may contain.
This was not always the case, specifically for ranges with
`from <= kMaxUint8` and `to > kMaxUint8`.
The reason this is so tricky: 1. not all parts of the pipeline know
whether we are compiling for one- or two-byte subjects; 2. for
case-insensitive regexps, an out-of-bounds CharacterRange may have an
in-bounds case equivalent (e.g. /[Ÿ]/i also matches 'ÿ' == \u{ff}),
which only gets added somewhere in the middle of the pipeline.
Our current solution is to clamp immediately before code emission. We
also keep the existing handling/dchecks of the 0x10ffff marker value
which may occur in the two-byte subject case.
Bug: v8:11069
Change-Id: Ic7b34a13a900ea2aa3df032daac9236bf5682a42
Fixed: chromium:1275096
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306569
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78186}
Enable the prefinalizers scope and add a top level AtomicSweep scope
so that prefinalizers are accounted as part of sweeping.
Change-Id: I9dade6a2367d30d20395de30c3db84922fee5a49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306567
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78185}
We sometimes use ReportError() inside of Torque parser actions.
The resulting exception prevented the ParseResultIterator from being
consumed completely, which in turn triggered a CHECK failure instead
of the correct error message.
Change-Id: Ie8dcdf67094e5ad5d68934e8a2921d5f52bd3092
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306973
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78184}
Add suppose for compiling non-eager, non-top-level inner functions in
parallel, using the compiler dispatcher. This behaviour can be enabled
with --parallel-compile-tasks-for-lazy.
There are a couple of consequences:
* To support this we need support for off-thread ScopeInfo
deserialization, so this adds that too.
* The previous --parallel-compile-tasks flag is renamed to the more
descriptive --parallel-compile-tasks-for-eager-toplevel.
* Both parallel-compile-tasks flags are moved onto
UnoptimizedCompileFlags so that they can be enabled/disabled on a
per-compile basis (e.g. enabled for streaming, disabled for
re-parsing).
* asm.js compilations can now happen without an active Context (in
the compiler dispatcher's idle finalization) so we can't get a
ContextId for metric reporting; we'd need to somehow fix this if we
wanted asm.js UKM but for now it's probably fine.
* Took the opportunity to clean up some of the "can preparse" logic in
the parser.
Change-Id: I20b1ec6a6bacfe268808edc8d812b92370c5840d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281924
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78183}
c++17 is being enabled on some platforms:
https://crrev.com/c/3306812
which causes gcc to emit the following warning:
```
error: null argument where non-null required (argument 2)
memcpy(storage_ + kReturnCount, param_types.data(),
~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Unlike clang, gcc is not able to detect if memcpy is actually
being executed or not when src is NULL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22179
Therefore need to disable this warning at this location.
Change-Id: I44da9f698ef724e39bb9c7d4b235d1004d52f491
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308916
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78182}
Try blocks (whether catch or finally) will unconditionally create
handler tables and start a new basic block for the exception handler.
This can accidentally resurrect a dead block when the entire try block
is dead (and hence can never enter the exception handler in the first
place).
Add a deadness check to BuildTryCatch/Finally to fix this.
Bug: chromium:1273677
Change-Id: Icda9deb1459e47de5cb83e7b636299e24c3ebe77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306555
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78179}
Some performance sensitive paths in V8 (compilation/json parsing) or
paths with high allocation/freeing throughput can suffer from not being
able to reuse recently freed allocations. These paths can also
significantly increase the working set and cause large number of page
faults. For such paths (at least as an initial measure) we are planning
to disable allocation quarantining.
The CL provides a way for the embedder to hook in *Scan functions that
disable/enable quarantining. It also disables *Scan for json parsing and
compilation jobs.
Bug: chromium:1249550
Change-Id: I0274f66010435f3d4d091fe70fabcd20f46dc0d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306389
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78178}
mksnapshot is compiled/ran in the host configuration (usually x64), we
need to propagate the flag (using bazel transitions) to tell mksnapshot
to generate code to a different architecture.
No-Try: true
Change-Id: I5923f5895872a8cbf2982925a545855a330c51fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306568
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78177}
Until now, LABs were accessed from generated code via external
references, e.g., see NewSpaceAllocationTopAddress() and
NewSpaceAllocationLimitAddress().
This patch places them in the IsolateData, so they can be accessed
using Isolate-constant offsets. It affects the hot path of all TF
generated code.
Bug: v8:12428
Change-Id: I7bfd54bea4febead404829d8e0b058b6cf53a374
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3303800
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78176}
Rolling v8/build: e0d5dbf..c829343
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/8cf0922..bd8b0c2
Rolling v8/third_party/depot_tools: 512ca5c..8676aa9
Rolling v8/third_party/googletest/src: e2f3978..bb92160
Rolling v8/tools/clang: 9c18fde..401e727
Rolling v8/tools/luci-go: git_revision:7422359d33c606e8adb0e9cf461837eb9b49431f..git_revision:e4c95e4e4cdc987f1860e4111589606bcd3a8f32
Rolling v8/tools/luci-go: git_revision:7422359d33c606e8adb0e9cf461837eb9b49431f..git_revision:e4c95e4e4cdc987f1860e4111589606bcd3a8f32
R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: Ia3f9d9b245812be6b54acbdff4a15bfe5c08a0d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308828
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#78173}
This avoids a compile error when building with GCC in C++17 mode.
Bug: v8:12449
Change-Id: I14817895d31019fb71fc71b061f2ecf576dbc711
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3307102
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78171}
For years win32-headers.h has "helpfully" set _WIN32_WINNT if it has not
already been set. This has caused problems because the value specified
in win32-headers.h falls behind that set in the config files. This
change removes the fallback and makes it an error to not set this macro
in the build config files.
This only affects MinGW builds where it has caused confusion.
Bug: v8:12099
Change-Id: I013aadc307376fa97afa7b7752910f4fa4a6db82
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272648
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78168}
Currently, JSFinalizationRegistry has a BodyDescriptor that iterates
next_dirty as a custom weak field, and it has a WeakListVisitor that
cleans up any items from the list that should be removed. However, none
of that code is used, because JSFinalizationRegistry objects are created
with visitor ID kVisitJSObjectFast. This change gives them a custom
visitor ID so that next_dirty can be treated as weak.
Bug: v8:12430
Change-Id: I31c1935257ad508b13a3e684662d2ca406d8ed19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3307096
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78167}
Add an approximate bailout for sweeping on allocation to avoid
reporting scopes when no work is being done.
Bug: v8:12286
Change-Id: I7589429805af702c35d51f9a37eae596268dedc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306983
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78166}
