On some branches of the search tree for a binary-search switch, the
input value is sufficiently constrained that we could unconditionally
jump to the last possible case rather than checking for value equality.
This shortens some builtins by a few instructions and might speed things
up, though I expect the effect to be small.
Change-Id: I2313f26976e6d3c182f03bd927b338c8175b3af3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3335437
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#78376}
Multiple threads can modify async_wraps_ in parallel, which is not ok.
Drive-by-fix:
- Use normal constructor/destructor for AsyncHooksWrap
- Use unique_ptr for storing AsyncHooksWrap
Bug: chromium:1278276
Change-Id: I667980151c775be29e603790e589b1de76fae05a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3338257
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78375}
This decouples the stack trace visitation logic from the creation
of actual stack frame objects, in preparation to introduce a
second kind of stack frame object (`v8::internal::StackFrameInfo`
as part of http://crrev.com/c/3302794) in addition to the existing
`v8::internal::CallSiteInfo`.
Doc: https://bit.ly/v8-stack-frame
Bug: chromium:1258599, chromium:1278647, chromium:1278650
Change-Id: I398933653e29cc2fe5c222526d9dd686ef8239b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3334781
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78374}
- Mark uncommon timer-paths as V8_NOINLINE
- Add explicit LongTaskNestedTimedHistogramScope class
- Use explicit LongTaskRecordMode enum
- Mark a few more isolate methods as const
- Add more timer scopes:
- Accessors::ArrayLengthSetter
- v8::NewContext
Bug: v8:12498, chromium:1275056
Change-Id: I7896ee341c3c3a1fd5acf8f3f59347ff01dda9c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3338258
Reviewed-by: Marja Hölttä <marja@chromium.org>
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78372}
We probably expect a binary-search switch to take log(n) time in all
cases, but there is currently a possibility of that expectation being
broken. I'm not aware of any place where this actually happens, but if
the default handler immediately follows the switch dispatch block in
assembly order, then unconditional jump instructions for that handler
would be omitted. This omission could cause linear execution time, where
every case is checked before falling through to the default handler.
This change introduces a new function to emit an unconditional jump
instruction regardless of whether the target is the following block, and
uses that new function when generating a binary-search switch to ensure
consistently log(n) behavior.
Change-Id: I5cab86fd66386762519035410e3b532dc6fd764c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3335222
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#78370}
With dynamic tiering, the "serialize" function provided by the c-api
does not work anymore, and it is unclear how it should work.
R=jkummerow@chromium.org
Bug: v8:12281
Change-Id: Ib70bf118ba42b0752eb5dab5f43893da0404931e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3338657
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78369}
An asm-js module has all wasm feature flags disabled, despite the global
flag configuration. Therefore, in WasmExportedFunction::New, we should
retrieve the enabled features from the NativeModule instead of the
flags.
Bug: chromium:1279151
Change-Id: Ic44fe535baa7cb851644457cce533c24d4c9824e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3338256
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78368}
This is a non-functional refactoring to make naming of stack traces more
consistent, and thus easier to reason about whether the "simple stack
trace" (stack trace API) or the "detailed stack trace" (inspector API)
is meant. Granted, these names aren't great by themselves, but at least
we should be consistent.
This also adds a new `Isolate::GetSimpleStackTrace()` and uses that
directly to implement the Wasm C-API, avoiding the roundtrip via the
`JSMessageObject`, which actually carries a detailed stack trace (which
by chance worked out so far).
Doc: https://bit.ly/v8-stack-frame
Bug: chromium:1258599, chromium:1278647, chromium:1278650
Change-Id: I29e1a956ed156d6eeceb50150a28afaa2f11b9c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3334780
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78366}
Use build_flags_ with @if/@ifnot in torque for the following flags:
- V8_ENABLE_JAVASCRIPT_PROMISE_HOOKS
- V8_ENABLE_SWISS_NAME_DICTIONARY
- Make sure Torque and CSA code actually respect
V8_ENABLE_JAVASCRIPT_PROMISE_HOOKS.
- Rename V8_ALLOW_JAVASCRIPT_IN_PROMISE_HOOKS to
V8_ENABLE_JAVASCRIPT_PROMISE_HOOKS
- Rename gn/bazel arg v8_allow_javascript_in_promise_hooks to
v8_enable_javascript_promise_hooks
- Unship context promise hooks in chrome and enable them only in d8
for testing purposes
- Make sure d8 and the API throw when using promise hooks without
the compile time feature enabled
Bug: chromium:1265186, v8:11025
Change-Id: I69834d44d683a36d0d7be3c3d68888321be0fd7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3301474
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78362}
This is the second step in the refactoring to make v8::StackFrame
more lightweight and usable for (long time storage) by the V8
inspector (see https://bit.ly/v8-stack-frame for an overview).
This is a purely mechanical change without any functional aspects.
The intention is to make the use case for the CallSiteInfo objects
clear, namely to serve as the backing store for the CallSite objects
exposed via the Error.prepareStackTrace() API and used under the
hood to implement the error.stack accessor.
Doc: https://bit.ly/v8-stack-frame
Bug: chromium:1258599, chromium:1278647, chromium:1278650
Change-Id: I39dffd1f1a8e5158ddc56f2a0a2b1b28321f487a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300138
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78361}
Some embedders might want to process console.info and console.log
differently. So inspector needs to return a different level for
these console log messages.
Change-Id: I936990a25f079a0d72f877a5095ed93819fc539a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3331929
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Alexey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78357}
We recently ran into two separate issues with this DCHECK. To enhance
debugging, let's add some more information as to which property is
failing. That should make investigating of the problematic property
easier, as we now no longer need to printf the results.
R=jkummerow@chromium.org
Bug: chromium:1276617, chromium:1262066
Change-Id: I8613780fc9613af700e113bb6050d4cbbd4cb040
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3330467
Commit-Queue: Tim Van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Tim Van der Lippe <tvanderlippe@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78353}
Since the reftypes proposal has shipped, we remove the respective flag
and the code that handled its absence. We maintain a WasmFeature for
reftypes for feature detection purposes. We remove the flag declaration
from tests, and adapt some tests that make no sense without the flag.
Bug: v8:7581
Change-Id: Icf2f8d0feae8f30ec68d5560f1e7ee5959481483
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3329781
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78351}
This is a reland of 863bc2b88a
Diff to original:
- Don't eliminate GC observable stores that were temporarily
unobservable during traversal.
- Skip the previously added test for single-generation
- Add new test
Original change's description:
> [turbofan] Improve StoreStoreElimination
>
> Previously, StoreStoreElimination handled allocations as
> "can observe anything". This is pretty conservative and prohibits
> elimination of repeated double stores to the same field.
> With this CL allocations are changed to "observes initializing or
> transitioning stores".
> This way it is guaranteed that initializing stores to a freshly created
> object or stores that are part of a map transition are not eliminated
> before allocations (that can trigger GC), but allows elimination of
> non-initializing, non-transitioning, unobservable stores in the
> presence of allocations.
>
> Bug: v8:12200
> Change-Id: Ie1419696b9c8cb7c39aecf38d9f08102177b2c0f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295449
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78230}
Bug: v8:12200, chromium:1276923, v8:12477
Change-Id: Ied45ee28ac12b370f7b232d2d338f93e10fea6b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320460
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78349}
This is a reland of 2418d22a37
Reland fixes:
* Rebase this 2+ year old change 😱
* Unpoison the kept segment before zapping it to make ASAN happy.
* Carefully adjust allocation size tracking fields to compensate for
kept segment.
Original change's description:
> [zone] Keep one page when we Zone::Reset for reuse
>
> Change-Id: I50c6124d3da5b35d4156c066f38d10d2dc966567
> Reviewed-on: https://chromium-review.googlesource.com/c/1349246
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57793}
Change-Id: Iaffde5b38b3d683af081b1878464dd4c66be5af8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322833
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78348}
This CL overrides the Summarize() method on the BuiltinExitFrame,
similar to what is already implemented on UnoptimizedFrame. This
way the stack trace capturing logic can be unified further, and
only needs to distinguish between JavaScript(ish) and WebAssembly
frames now.
Bug: chromium:1258599, chromium:1278650, chromium:1278647
Change-Id: I15f4dd61199ff047930796ce285bd938e8bcd22f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3327142
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78347}
With a recent addition to the type reflection proposal, 'anyfunc' gets
renamed to 'funcref'. For backwards compatibility, 'anyfunc' becomes an
alias for 'funcref'. With this CL, the string 'funcref' can be used to
create a funcref table or a funcref global. Additionally, 'funcref' is
returned as the type of imported and exported functions as well as
globals and tables.
R=manoskouk@chromium.org
Change-Id: If3ed4d507de862ebfcabd4eb967bbfaae1c6ccba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300135
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78341}
Fix is applied to some of halfword signed ops.
Change-Id: Idad3cfe9b66d39cb991974c959d447e5c4eccad3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3327722
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78340}
Currently atomic ops on TF are using machine native byte order
and cannot be used by Wasm calls.
This Cl adds support for Little Endian enforced Wasm atomic ops
to PPC/AIX by reversing bytes where needed.
Change-Id: I4080f318022eedd2058e51d09595753eab385441
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3327721
Reviewed-by: Vasili Skurydzin <vasili.skurydzin@ibm.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78339}
This allows us to reuse AstValueFactory's string table across multiple
parsers, while still releasing memory after each individual parse.
This is mild overkill for all the single parses that don't reuse
AstValueFactories, but there at least the AstRawStrings now end up
grouped together in memory, so that might have mild cache benefits.
Change-Id: I0b378760b601fa4ec6559a0dca5d7ed6f895e992
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322764
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78338}
To make sure that Wasm memories don't exceed JSArrayBuffer size.
This change shouldn't affect real-world modules, because finding
enough contiguous address space to allocate that much memory is
virtually impossible anyway.
Fixed: chromium:1242339
Change-Id: I68873796b9afb798cb1a64e5e1acc495cf509159
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328783
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78336}
Some bad rebasing meant that we were still deleting on the main thread.
As an additional simplification, remove the specific deletion queue
mutex, and just use the compiler dispatcher mutex for the deletion queue
-- this avoids risks of deadlock when both are held.
Change-Id: Ifa4ead6ee3fd814d7f013dd14a5617456afc9f7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328785
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78335}
Rather than requiring the user of a LocalIsolate to pass in a
RuntimeCallStats from a WorkerThreadRuntimeCallStatsScope, create the
scope in the LocalIsolate directly and use its RuntimeCallStats in the
LocalIsolate constructor.
We can't do this for the main thread LocalIsolate, since
WorkerThreadRuntimeCallStatsScope doesn't work on the main thread, so
there we use the main-thread RuntimeCallStats instead.
This flushes out some issues of background-thread LocalIsolates being
used on the main thread, so fix those too, as well as RCS scopes using
background counters for operations that could happen on the main thread.
Change-Id: I21a53be0771f47a03ccdb27d24c2b9d25d8b2d1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318664
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78334}
Stub calls generated in wasm-compiler were not marked as kNoThrow. This
created an inconsistency where these ostensibly throwing calls did not
get wrapped in exception handlers, which in turn creates problems in
upcoming changes in inlining.
We resolve the inconsistency by marking all such calls as kNoThrow.
Exceptions are the throwing calls Throw and Rethrow, for which we create
exception handlers in WasmGraphBuildingInterface::CheckForException.
Change-Id: I81da1b191332bcd497116e9f82e4de198778086b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322836
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78333}
During a shared GC we need to iterate the twice: for marking and later
when updating pointers after evacuation. This CL introduces a new
remembered set to avoid the second heap iteration, the remembered set
is created when iterating the client heaps for marking. When updating
pointers, the GC only needs to visit slots in the remembered set.
CLIENT_TO_SHARED is only used during GC atm.
Bug: v8:11708
Change-Id: Ie7482babb53b5f6ca2115daafe6f208acae98d6e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3315443
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78332}
Rolling v8/build: 9cfc745..312246f
Rolling v8/buildtools/third_party/libc++abi/trunk: 89f2e82..d520ea5
Rolling v8/buildtools/third_party/libunwind/trunk: c8c0ec9..d81cd62
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/4983973..d16203a
Rolling v8/third_party/depot_tools: 0a233e1..58c7c38
Rolling v8/third_party/googletest/src: 4c5650f..054a986
Rolling v8/tools/clang: 336fcfd..ed8451a
Rolling v8/tools/luci-go: git_revision:31175eb1a2712bb75d06a9bad5d4dd3f2a09cd1f..git_revision:e897e118887a2e6c50a82212b660cb2a7c58d910
Rolling v8/tools/luci-go: git_revision:31175eb1a2712bb75d06a9bad5d4dd3f2a09cd1f..git_revision:e897e118887a2e6c50a82212b660cb2a7c58d910
R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: If2bd3d5e3c62c274ab71b01a562370e7a77bf980
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3327745
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@{#78330}
