Give the "phantom" script containing the web snapshot functions the same
name as the original script.
Bug: v8:11525
Change-Id: Iae77d58152642256560ceb3688bc2b3d0d9800be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3394707
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78643}
The receiver is included unconditionally on all platforms
(kJSArgcIncludesReceiver is always true).
Remove all usages of kJSArgcIncludesReceiver from the code.
Bug: v8:11112
Change-Id: I7d62e6de65b73fe6d8c3293f32b500b760b08a3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322980
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78642}
As described in https://crbug.com/1287476, the fact that the
AsyncEventDelegate is currently implemented on top of the PromiseHooks
causes performance problems and makes it difficult to reason about the
exact (observed) semantics; this is because for this we intercept every
JSPromise creation (via PromiseHook::kInit) and walk the synchronous
stack at that point to see if we find one of Promise#then(),
Promise#catch() or Promise#finally() on the stack. And if we do so, we
report that to the AsyncEventDelegate (which is implemented in the
inspector and will then do the async stack/stepping logic on top).
This CL introduces dedicated instrumentation for Promise#then(), which
is also called from Promise#catch() and Promise#finally(), and uses that
instrumentation for the purpose of the AsyncEventDelegate. It also
adjusts the stack walk to not always walk the full stack (which might
lead to wrong results when calls to Promise#then(), which itself can
call back into user JavaScript, are found deeper in the stack), but
instead only check the top-most builtin frames and whatever user
JavaScript frame is underneath it.
On the standalone.js (from https://crbug.com/1287476#c1), when run with
the DevTools default of maxDepth=200, we go from around 4.00ms to around
0.36ms. For everything that does not call Promise#then() - either
explicitly or implicitly - or `await`s, there's now no observable
performance impact of turning on the AsyncEventDelegate.
Bug: chromium:1280519
Fixed: chromium:1287476
Change-Id: I4911bed146381fc46cfeefb763d6dfc32e8f6071
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386379
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78640}
The fast path has an early return if the two inputs are the same
object. However, this was missing the check that the receiver
is not undefined required by the spec.
This fixes it by first checking that the receiver is a string and
only afterwards checking for reference equality.
Bug: v8:12495
Change-Id: I4c5fc80e09060b013c94b05bbc9da504ddbb5206
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386602
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78637}
Shell::FetchModuleTree assumes that the module at file_name wasn't
already fetched. Shell::ExecuteModule is calling into
FetchModuleTree without checking if the module is already in the module
map, violating this assumption.
This change fixes this by having Shell::ExecuteModule check for the
existence of the module before calling into Shell::ExecuteModule, the
same way that Shell::DoHostImportModuleDynamically does.
Bug: v8:12530
Change-Id: Ia038cbd1715e85c9c92c4554fd486c657ef952e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3388130
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78636}
Similar to the case of fixed registers, we need to consider both cases:
A SIMD register might collide with either the low or high FP register,
or the FP register might collide with a previously allocated SIMD
register. We did only consider the first case so far.
R=thibaudm@chromium.org
Bug: chromium:1286253, v8:12330
Change-Id: Id4c995586cc8b97a2e131ee9d3417525e409bcef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380597
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78633}
For getting from one SIMD "sibling" register to the other, the mid tier
register allocator was relying on the indexes of the two registers to be
{2N} and {2N+1}. This is only true for lower SIMD registers; later
registers can be at {2N-1} and {2N} instead, because of holes in the
allocatable double registers (e.g. d13-d15 are not allocatable currently
on ARM).
We can rely on other facts though:
1) The two aliasing registers are always successive.
2) A SIMD register code always maps to the lower register index.
3) We can get from an F32 register code to F64 and from F64 to S128 by
shifting one bit to the right (this is what
{RegisterConfiguration::GetAliases} uses).
This bug was uncovered by running the existing
cctest/test-code-generator/FuzzAssemble* tests with either
--turbo-use-mid-tier-regalloc-for-huge-functions or with
--turbo-force-mid-tier-regalloc. Hence it will be covered by these tests
once https://crrev.com/c/3347822 lands.
R=thibaudm@chromium.org
TEST=cctest/test-code-generator/FuzzAssemble*
Bug: v8:12330
Change-Id: I168840fe50b6ba6cdaa6a5462596a5cbf55c87ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3378782
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78632}
This is a reland of 142dd775b4
Original change's description:
> cppgc-js,heap: Implement snapshots for embedder fields
>
> https://crrev.com/c/3293410 added concurrent processing of C++ objects
> found through V8 embedder fields. The CL missed that those embedder
> fields are not read atomically from JS objects. The problem is that
> embedder fields are only aligned to kTaggedSize on builds with pointer
> compression and are as such mis-aligned for atomic ops. This is not a
> problem for on-heap values as the upper 32bits are anyways computed
> from the cage. Is is a problem for generic C++ values though, as they
> are used with Oilpan.
>
> This CL adds the standard marker snapshot protocol for embedder fields.
>
> Marker:
> 1. Snapshot embedder fields
> 2. Try to mark host object
> 3. On success: process snapshot
>
> Main thread:
> 1. On setting embedder fields mark the object black first
> 2. Emit a write barrier for the embedder fields
>
> This will get simpler with the heap sandbox that uses a separate table
> for embedder fields. Once the sandbox is the default configuration, we
> can use it as dependency for the concurrent fast path.
>
> Bug: chromium:1285706
> Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78604}
Bug: chromium:1285706
Change-Id: I024e50fc0757fbcd13cb9ffde027dff55f99d25c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386600
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78631}
Implementations are added to macro-assembler to be shared between
liftoff and code generator.
Change-Id: I945e312b45d87e021ffd64948bdfd69d0642fb83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3387608
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78630}
- Add suspend asm builtin stub, and call it from the suspending
wasm-to-js wrapper
- Rename frame type to match both builtins (prompt and suspend)
- Add suspend bool to the import cache key
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: Ie5a8ca7cbe4bcb91697e05b6470e3d632d608993
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345004
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78628}
Following up on https://crrev.com/c/3383775 I realized that we could
just use the existing %DebugPopPromise and %DebugPushPromise runtime
functions, which do exactly the same job as %DebugAsyncFunctionFinished
and %DebugAsyncFunctionResumed, and are already used in other places of
promise instrumentation.
We can also remove %DebugAsyncFunctionEntered and utilize the logic in
NewJSPromise() to deal with the various promise hooks, and otherwise go
with %DebugPushPromise for the debugger side.
Bug: chromium:1280519
Change-Id: I79c77236f19c8783161c1eee36d2a16d52c60e82
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386382
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78626}
This reverts commit f605d77822.
Reason for revert: Segfaults: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/36908/overview
Original change's description:
> [runtime] Adds LocalNameIterator
>
> ScopeInfo will contain either inlined (array) local names or
> a hash table (names => index) containing the local names.
>
> We abstract iteration with LocalNameIterator and remove
> ContextLocalName since accessing a local name by index in
> the hash table would be expensive.
>
> This CL only implements the iterator for the array.
>
> Bug: v8:12315
> Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78623}
Bug: v8:12315
Change-Id: Ibabe231f4357a3dd02d24b89847d579b83867a1a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386385
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78625}
The Isolate might not be aware that remapped builtins are used (see
Code::OffHeapInstructionStart()), so always try to lookup PC in the
remapped builtins if they are available.
This is a follow-up to
https://chromium-review.googlesource.com/c/v8/v8/+/3379817.
Bug: chromium:1241665, v8:11460
Change-Id: Ied59ce6c7920278ed701e7139c8b6839a04cf1cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386381
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78624}
ScopeInfo will contain either inlined (array) local names or
a hash table (names => index) containing the local names.
We abstract iteration with LocalNameIterator and remove
ContextLocalName since accessing a local name by index in
the hash table would be expensive.
This CL only implements the iterator for the array.
Bug: v8:12315
Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78623}
kScopeInfoMaxInlinedLocalNamesSize is a threshold for inlined storage,
otherwise local names will be stored in a hash table.
Bug: v8:12315
Change-Id: Ibfa5bec5222c9e60765c3663707623544895ec0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386601
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78622}
ScopeInfo will contain either inlined (array) local names or
a hash table (names => index) containing the local names.
If we have the local names inlined, we should save the class
variable context slot index.
If we have a hash table instead, we should save the class
variable offset in the internal hash table storage.
Bug: v8:12315
Change-Id: Ifd9ae4f285d11fc034e8560c8558038b38a474fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386599
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78621}
This CL removes the global IsValidBackingStorePointer function and turns
the DCHECKs that ensure that sandboxed pointers point into the sandbox,
which essentially cover the same condition, into CHECKs. This is mostly
to facilitate debugging during the initial rollout, and the CHECKs can
later be turned back into DCHECKs.
In addition, this CL adds a fallback to a partially-reserved sandbox
when sandboxed pointers are enabled and when the regular initialization
fails.
Bug: chromium:1218005
Change-Id: I75526f1a00ddb9095ae0e797dc9bb80a210f867b
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3367617
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78620}
InvokeSecondPassPhantomCallbacks() may allocate which may result in a different GC selection.
Bug: v8:12503
Change-Id: I936634f9b819bc160749e058cbee8fb1c555f376
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386800
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78619}
Since ManualGCScope changes marking flags it should finalize any
ongoing GC before changing the flags. Otherwise, the GC may observe
inconsistent state.
Bug: chromium:1285706
Change-Id: Ie8ef6a1117ba0523d0bed0c46d9116ffbc02069c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386607
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78618}
When FLAG_shared_string_table is true, postMessaging strings will share
instead of copy.
Note that not all operations on shared strings are supported, and shared
strings may be slower than non-shared strings for some operations.
Bug: v8:12007
Change-Id: I3462128e15410d2568868143571571b3025722c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277250
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78614}
Use grep to check for obviously unneeded includes. e.g. headers that
include <vector> but does not contain "std::vector".
Change-Id: I43a9e9f01e072fd495918d28ca4cdad5cfa0294c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3354400
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78613}
The total wall time for GC reported to Blink is explicitly included in
UMA events. For the C++ managed heap, it is equal to the sum of the four
phases (mark, sweep, compact, weak). For the JS heap, it will be greater
than or equal to that sum in general.
Bug: chromium:1154636
Change-Id: Id710702b8e9d8db5c8d1eb4917deb6b760a77306
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386596
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78611}
Following up on https://crrev.com/c/3383775 we are now able to further
simplify the implementation of `await` and its instrumentation (for both
debugger and promise hooks), which aligns the implementation more
closely with the spec text and removes a whole bunch of unnecessary
code.
This also moves the `await` instrumentation into runtime-debug.cc along
with the other instrumentation methods for async functions.
Bug: chromium:1280519, chromium:1277451, chromium:1246867
Change-Id: I3fb543c76229091b502f3188da962784977158ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386597
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78610}
When initializing a table entry with null or a function constant, do not
go through EvaluateInitExpression. Remove the option to treat functions
lazily in EvaluateInitExpression/InitExprInterface.
Drive-by: Shrink indirect tables by removing redundant field.
Bug: chromium:1284557
Change-Id: I78a64becebf4b967b0a440d43855e163ec190b7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383135
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78608}
This reverts commit 142dd775b4.
Reason for revert: TSAN breaks: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/6113/overview
Original change's description:
> cppgc-js,heap: Implement snapshots for embedder fields
>
> https://crrev.com/c/3293410 added concurrent processing of C++ objects
> found through V8 embedder fields. The CL missed that those embedder
> fields are not read atomically from JS objects. The problem is that
> embedder fields are only aligned to kTaggedSize on builds with pointer
> compression and are as such mis-aligned for atomic ops. This is not a
> problem for on-heap values as the upper 32bits are anyways computed
> from the cage. Is is a problem for generic C++ values though, as they
> are used with Oilpan.
>
> This CL adds the standard marker snapshot protocol for embedder fields.
>
> Marker:
> 1. Snapshot embedder fields
> 2. Try to mark host object
> 3. On success: process snapshot
>
> Main thread:
> 1. On setting embedder fields mark the object black first
> 2. Emit a write barrier for the embedder fields
>
> This will get simpler with the heap sandbox that uses a separate table
> for embedder fields. Once the sandbox is the default configuration, we
> can use it as dependency for the concurrent fast path.
>
> Bug: chromium:1285706
> Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78604}
Bug: chromium:1285706
Change-Id: If1976c0356f450fc068aa4dcc39fb9a0d5417a40
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386598
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#78605}
https://crrev.com/c/3293410 added concurrent processing of C++ objects
found through V8 embedder fields. The CL missed that those embedder
fields are not read atomically from JS objects. The problem is that
embedder fields are only aligned to kTaggedSize on builds with pointer
compression and are as such mis-aligned for atomic ops. This is not a
problem for on-heap values as the upper 32bits are anyways computed
from the cage. Is is a problem for generic C++ values though, as they
are used with Oilpan.
This CL adds the standard marker snapshot protocol for embedder fields.
Marker:
1. Snapshot embedder fields
2. Try to mark host object
3. On success: process snapshot
Main thread:
1. On setting embedder fields mark the object black first
2. Emit a write barrier for the embedder fields
This will get simpler with the heap sandbox that uses a separate table
for embedder fields. Once the sandbox is the default configuration, we
can use it as dependency for the concurrent fast path.
Bug: chromium:1285706
Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78604}
This CL fixes 2 issues with string internalization when the string table
is shared:
1. In-place migration of a string's map to Internalized was done before
it was sure that the string is going to be internalized (outside the
critical section). To fix this problem StringTableKey::AsHandle() is
now split into StringTableKey::PrepareForInsertion(), which is
invoked outside the critical section and creates a copy if
necessary, and StringTableKey::GetHandleForInsertion(), which is
invoked inside the critical section only for string table misses.
Migration of the map is handled by this method.
2. TryStringToIndexOrLookupExisting() didn't handle already internalized
strings. So far this was impossible, as this method was only invoked
for strings that were checked not to be internalized. However with
a shared string table, the string could be internalized after the
checks.
Bug: v8:12007
Change-Id: I193d6b54dc41360eee47d21cbcaa36d2652d85dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3368103
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78600}
This unifies and simplifies the way we instrument async functions for
the purpose of async stack traces and async stepping. It does so while
retaining the observable behavior on the inspector level (for now).
Previously we'd mark the implicit promise of the async function object
with the async task ID, and whenever we awaited, we'd copy the async
task ID to the throwaway promise that is created by the `await`. This
however made things unnecessarily interesting in the following regards:
1. We'd see `DebugDidHandle` and `DebugWillHandle` events after the
`AsyncFunctionFinished` events, coming from the throwaway promises,
while the implicit promise is "done". This is especially confusing
with rejection propagation and requires very complex stepping logic
for async functions (after this CL it'll be possible to unify and
simplify the stepping logic).
2. We have to thread through the "can suspend" information from the
Parser all the way through AsyncFunctionReject/AsyncFunctionResolve
to the async function instrumentation to decide whether to cancel the
pending task when the async function finishes.
This CL changes the instrumentation to only happen (non recurringly) for
the throwaway promises allocated upon `await`. This solves both problems
mentioned above, and works because upon the first `await` the stack
captured for the throwaway promise will include the synchronous part as
expected, while upon later `await`s the synchronous part will be empty
and the asynchronous part will be the stack captured for the previous
throwaway promise (and the V8Debugger automatically short circuits
stacks with empty synchronous part).
Bug: chromium:1280519, chromium:1277451, chromium:1246867
Change-Id: Id604dabc19ea133ea2e9dd63181b1fc33ccb5eda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383775
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78599}
CompleteInobjectSlackTracking potentially shrinks multiple maps, and
the relation between these maps should be preserved in a concurrent
environment. Thus it is not enough to make each modification
atomically, but all related map modifications must be within a
critical section.
We do this by locking the map_updater_access mutex
CompleteInobjectSlackTracking, and hence moving the function to the
MapUpdater class.
Bug: chromium:1274445,v8:7990
Change-Id: If99bb8b55e03180128ee397d845fa4c269c4241e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379819
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78597}
Implementations are added to macro-assembler to be shared between
liftoff and code generator.
Change-Id: Ibe326a80f71cad41dadbb62ebbcb9b8797f1871f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3384540
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78593}
The field is updated on the main thread and read on threads using
LocalHeap to possibly trigger GC in fuzzing configurations.
Bug: chromium:1286699
Change-Id: I15330b7542358ce1a2307a1f258655126b252c03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383776
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78591}
We might run TRACE_GC with ThreadKind::kMain not only on each isolate's
main thread but also on the shared isolate's thread during a shared GC.
The DCHECK is too restrictive for the latter case. This is safe because
the shared GC will stop all main threads before starting its work.
Bug: v8:11708
Change-Id: I1f40140d6502b1ec797dfa783fb693ed213efb3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380522
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78588}
Provide a stub `third_party_heap::Heap` implementation to work around
linker erors with Visual Studio.
Refs: https://github.com/bnoordhuis/v8-cmake/pull/50
Bug: v8:10427
Change-Id: I435081d8cb195d1db999db699df3d3751663c81d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366367
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78587}
CDP has a "ExceptionDetails" structure that is attached to various
CDP commands, e.g. "Runtime#exceptionThrown" or "Runtime#evaluate".
The stack trace in the "ExceptionDetails" structure is used in
various places in DevTools. The information in the "ExceptionDetails"
structure is extracted from a v8::Message object. Message objects
are normally created at the exception throw site and may augment
the error with manually inspecting the stack (both to capture a fresh
stack trace in some cases, as well as to calculate location info).
The problem is that in some cases we want to get an "ExceptionDetails"
structure after the fact, e.g. when logging a JS "Error" object in
a catch block. This means we can't reuse Isolate::CreateMessage as
the JS stack at call time is unrelated to the time when an Error
object was thrown.
To re-use some of the code, this CL introduces a new
"CreateMessageFromException" method that is only available from the
debugging interface (not public V8 API!). The new method works
similar to Isolate::CreateMessage, but:
1) Does not look at the current JS stack, neither for a fresh
stack trace nor for location information.
2) Only uses the "detailed" stack trace for location info.
This is because the "simple" stack trace could have already
been serialized by accessing Error#stack.
Bug: chromium:1278650
Doc: https://bit.ly/runtime-get-exception-details
Change-Id: I0144516001c71786b9f76ae4dec4442fa1468c5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3337257
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78586}
Strengthen the assertion in CallFunction, that only callable functions
(not class constructors) are passed.
Change-Id: I2dc2d061cdc9930b5b8926285f021f9772e97570
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380529
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78585}
This is a reland of 86038ecfdc
Compared to the previous CL this one is adding a TSAN suppression
for GlobalSafepoint::EnterSafepointScope. local_heaps_mutex_ of client
isolates may be locked in any order. This would be detected by TSAN as a
potential race. Add some additional DCHECKs to compensate for that
missing test coverage.
As a cleanup this CL also removes the unused methods ContainsLocalHeap()
and ContainsAnyLocalHeap() from LocalHeap.
Original change's description:
> [heap] Optimize time to reach global safepoint
>
> Initial support for global safepoints kept it simple by entering a
> safepoint for each of them one after another. This means
> time-to-global-safepoint is the sum of all time-to-safepoint operations.
> We can improve this slightly by splitting up the safepoint iteration
> into two operations:
>
> 1) Initiate safepoint lock (locks local_heaps_mutex_, arms the barrier
> and sets SafepointRequested flag for all client threads)
> 2) Block until all runnning client threads reach a safepoint
>
> We now perform operation 1) for all clients first and only then start
> with operation 2).
>
> Bug: v8:11708
> Change-Id: Iaafd3c6d70bcf7026f722633e9250b04148b3da6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310910
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78308}
Bug: v8:11708, v8:12492
Change-Id: I7087ba23c08f2d4edb9b632eef3c218fc76342e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328786
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78583}
- Add an ActiveSuspender root, similar to the ActiveContinuation root.
- Add the missing "parent" field to the Suspender, which points to the
outer Suspender when they are nested, and update that field when
entering a new Suspender.
- Add the missing "state" field and update it when the state of the
Suspender changes.
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: I7a95f44f81390a347c6ef252ec6184fb4f0b0455
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345003
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78582}
This CL contains minor refactorings to some parts of the garbage
collector:
- Space iterators.
- Removes a redundant call to Heap::CreateFillerObjectAt.
- Heap::CompleteSweepingFull now ensures that sweeping in the C++
managed heap is also completed.
- Checks, comments and code cleanup.
Change-Id: I14a7fe45c270c463c94c86f45b0e65757249d548
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3377125
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78581}
This CL doesn't change behavior, only refactors MemoryAllocator:
* De-templatify class, MemoryAllocator is used on slow path and doesn't
really need templates for performance.
* Rename FreeMode names
* Move methods into private section of class
Change-Id: I7894fba956dcd7aa78ad0284d0924662fef4acae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379812
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78580}
The Isolate might not be aware that remapped builtins are used (see
Code::OffHeapInstructionStart()), so always try to lookup PC in the
remapped builtins if they are available.
Bug: chromium:1241665, v8:11460
Change-Id: Iefc373cf0ea0110c8c002b7677e6a1fd8fd45319
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379817
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78579}
We introduce {ConstantExpression}, which represents the most frequent
constant expression types directly, and falls back to a {WireBytesRef}
for the rest. During module decoding, we decode the most common
expressions separately and store them as {ConstantExpression}, so we do
not have to decode them again during module instantiation.
Bug: chromium:1284557
Change-Id: Ie411bbe9811d0d9f6e750ba202bb0ccff801dfee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3378347
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78576}
To make sure print the correct gc_count in heap layout tracer.
Change-Id: I790d9359acab188bbfd1f59b731531c58713d8f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3361842
Auto-Submit: Jianxiao Lu <jianxiao.lu@intel.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Jianxiao Lu <jianxiao.lu@intel.com>
Cr-Commit-Position: refs/heads/main@{#78575}
It is possible for KeyedDefineOwnICKind to go into
ElementsTransitionAndStoreIC_Miss when a computed field key
is a valid index and the lazy feedback allocation is disabled.
Bug: chromium:1277863
Change-Id: If8a81384257647426607495b6e3d8f235913e8f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322634
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#78573}
Vector load/store lane, splat, extend as well as load 32/64 zero
have been rewritten to make use of new z15 instructions (or use
older instructions if not available) in such Cls:
https://crrev.com/c/3138212https://crrev.com/c/3144373
Same has been done for PPC BE (AIX).
As a result the workarounds in wasm-compiler are no longer needed.
Change-Id: I1de7066fa20f6e4d9d68c1a6db77a164dc8ae2f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379820
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78572}
This is a temporary solution so prototyping of shared structs and shared
strings can be worked on in parallel.
Bug: v8:12007
Change-Id: Ic849ec66da1d3824d50d695f16e4b77380afa015
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379222
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78570}
V8 crashed with a FATAL when memory allocation during instantiation
failed. With this CL, a RangeError is thrown instead.
This is not the only possible OOM that can happen during the startup of
a WebAssembly app, but since the allocation of WebAssembly memory is
among the biggest allocations, this change may already prevent several
crashes.
R=clemensb@chromium.org
Bug: chromium:1268898
Change-Id: I9376830ba2fe9df62b5595b6b19c92e35a75dfda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380586
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78569}
Windows requires additional writable page to be allocated in front of
the code range, but at the same time the code range must not cross 4 GB
boundary in order to make Code pointer compression work for Code
pointers. All these constraints make the logic of hint calculation too
dependent on what VirtualMemoryCage::InitReservation() would do with
the provided hint. This CL simplifies the hint calculation and fully
relies on VirtualMemoryCage::InitReservation() to do the right thing.
On Linux the implementation of OS::GetFreeMemoryRangesWithin() doesn't
work when Chromium sandbox is enabled, so we use the beginning of the
preferred short builtin calls region as a hint. It should be at least
as good as the fallback hint but with higher chances to point to free
address space location.
Bug: v8:11880
Change-Id: I0b6ebec98dd0cf483f67e6ba8a919deb9ce7cc25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380585
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78568}
This CL takes advantage of the P9 `vector byte-reverse`
instructions to add to support to BE platforms.
Change-Id: Ia022e056ca61373b7f8f7754ec76e94774b80af3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3378922
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78566}
We introduce a type arrayref, which is a supertype of all array types
and a subtype of dataref. We change array.len to accept values of type
(ref null array).
Drive-by: Fix kEq/kData case in TypecheckJSObject.
Bug: v8:7748
Change-Id: I47c6a4487ddf5e7280c1427f43abe87a97c896bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3368105
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78565}
The original CL introduced a test that does not work when it is executed
concurrently on multiple isolates. This CL skips this test
configuration.
Original change's description:
> [wasm] Lazy compilation after deserialization
>
> The serialization format contains one boolean flag per function which
> specifies whether the function code exists in the serialized module or
> not. With this CL, this boolean flag is extended to a three-value flag
> which indicates whether the function exists, and if not, whether the
> function was executed before serialization. This information can then be
> used upon deserialization to compile only those functions that were
> executed before serialization.
>
> Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
>
> Bug: v8:12281
Change-Id: I36ce90b37736172aa01c47ab04e154ec8ea2d8aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380590
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78564}
- Add Suspender.suspendOnReturnedPromise method
- Extend the WasmApiFunctionRef data with the suspender
- Detect wrapped WasmJSFunctions when we resolve the import
For now the generated wrapper is still a regular wasm-to-js wrapper, but
this sets the ground for generating specific wrappers for functions
wrapped by suspendOnReturnedPromise, and to access the suspender from
the wrapper code.
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: I81cbec6b023507e47e6e1463b5f9b912f807da6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345000
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78560}
BaseSpace classes. So BaseSpace should have a virtual destructor
for memory to be freed properly.
cppgc: :internal::RawHeap maintains a std::vector of
std: :unique_ptr<BaseSpace> and stores there different derived from
Change-Id: Id9f59817799303bf62aafb66b3a29770bbd2af1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379228
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Alexey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78558}
The methods in the v8::internal::Factory deal with creating the objects
described in src/objects, so there's no point in having different sets
of owners for them.
Bug: none
Change-Id: I05b48535bd81d37796e3f741156a059be8554759
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359634
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78557}
This reverts commit fbcdb28178.
Reason for revert: New test fails for multiple (concurrent) isolates: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux/45152/overview
Original change's description:
> [wasm] Lazy compilation after deserialization
>
> The serialization format contains one boolean flag per function which
> specifies whether the function code exists in the serialized module or
> not. With this CL, this boolean flag is extended to a three-value flag
> which indicates whether the function exists, and if not, whether the
> function was executed before serialization. This information can then be
> used upon deserialization to compile only those functions that were
> executed before serialization.
>
> Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
>
> Bug: v8:12281
> Change-Id: I465e31e5422fa45163256be0e6594045865f0174
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364089
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78545}
Bug: v8:12281
Change-Id: If0e327d02e8257a4d1cfcf8b82381af11f28e91c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3377126
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#78546}
The serialization format contains one boolean flag per function which
specifies whether the function code exists in the serialized module or
not. With this CL, this boolean flag is extended to a three-value flag
which indicates whether the function exists, and if not, whether the
function was executed before serialization. This information can then be
used upon deserialization to compile only those functions that were
executed before serialization.
Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
Bug: v8:12281
Change-Id: I465e31e5422fa45163256be0e6594045865f0174
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364089
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78545}
This CL takes advantage of the P9 `vector byte-reverse`
instruction to implement Simd LoadSplat opcodes.
We will need to implement the rest of the `load transform` ops
before enabling this from wasm-compiler on BE machines.
Change-Id: I094e37d3b15e0dc04484eb2a701cb479f18e2f9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3371790
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78544}
When creating a new JSError object (or using the non-standard API
`Error.captureStackTrace`) V8 would previously capture the "simple stack
trace" (as FixedArray of CallSiteInfo instances) to be used for the non-
standard `error.stack` property, and if the inspector was active also
capture the "detailed stack trace" (as FixedArray of StackFrameInfo
instances). This turns out to be quite a lot of overhead, both in terms
of execution time as well as memory pressure, especially since the
information needed for the inspector is a proper subset of the
information needed by `error.stack`.
So this CL addresses the above issue by capturing only the "simple stack
trace" (in the common case) and computing the "detailed stack trace"
from the "simple stack trace" when on demand. This is accomplished by
introducing a new ErrorStackData container that is used to store the
stack trace information on JSErrors when the inspector is active. When
capturing stack trace for a JSError object while the inspector is
active, we take the maximum of the program controlled stack trace limit
and the inspector requested stack trace limit, and memorize the program
controlled stack trace limit for later formatting (to ensure that the
presence of the inspector is not observable by the program).
On the `standalone.js` benchmark from crbug.com/1283162 (with the
default max call stack size of 200) we reduce execution time by around
16% compared to ToT. And compared to V8 9.9.4 (the version prior to the
regression in crbug.com/1280831), we are 6% faster now.
Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
Bug: chromium:1280831, chromium:1278650, chromium:1258599
Bug: chromium:1280803, chromium:1280832, chromium:1280818
Fixed: chromium:1283162
Change-Id: I57dac73e0ecf7d50ea57c3eb4981067deb28133e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366660
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78542}
LocalFactory::AllocateRaw() only allows the kOld and kSharedOld
allocation types, but NewArrayList() calls NewFixedArray() without
an explicit allocation argument, which then defaults to kYoung.
Add an allocation argument to NewArrayList() with the same default
value as for NewFixedArray() and pass kOld when calling it from
NewScriptWithId() to avoid tripping the DCHECK with LocalFactory.
Follow-up to https://crrev.com/c/3211575
Bug: chromium:1244145
Change-Id: I88d394bda250c45bf49141b78c09f6ca4a61dbe3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3354087
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78540}
The special symbols defined in heap-symbols.h were extracted out of
src/heap/heap.{cc,h} a long time ago because they logically belong to
the objects and not to the implementation of the GC/heap, so they should
have the same ownership as the objects that use them in src/objects.
Bug: none
Change-Id: I9a87c1600dc26b0fc5e620a13d409fb9116235e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3375546
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78539}
We should only check the "SIMD sibling" register if we are handling a
SIMD register. This avoids unneeded spills, and in this particular case
ran into a DCHECK because there are only 29 registers, but we tried
checking #29.
R=thibaudm@chromium.org
Bug: v8:12330, v8:1285007
Change-Id: Ife8b295ac958990611ca8816bbfbfb5124a4297d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372916
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78532}
This is a reland of be6bd4f448.
The reason for revert was two bots timing out. On further inspection,
the timeouts seem unrelated.
Original change's description:
> [wasm] Fast paths in EvaluateInitExpression
>
> We add fast paths for the most common types of expressions in
> {EvaluateInitExpression} to improve instantiation time. We fall back to
> full expression decoding for less common operators, or for expressions
> with operands.
>
> Bug: chromium:1284557
> Change-Id: I39a1816176974058b801cdad6eaaa6da156cea04
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3367627
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78497}
Bug: chromium:1284557
Change-Id: I209458c1fa36ae41899434b90759ebe3fe5e2a57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3375545
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78529}
Inlining the field accesses make the code simpler by avoiding the
abstraction of the accessor, and makes stepping through the code for
debugging easier.
R=thibaudm@chromium.org
Bug: v8:12330
Change-Id: I51bd0e88baa5ffba5bd4bfcca36e95caab7468c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372913
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78521}
Since the accessors are only called from other methods in the same
class, we can just access the field directly. This makes stepping
through easier and makes the code simpler by avoiding an unneeded
abstraction.
R=thibaudm@chromium.org
Bug: v8:12330
Change-Id: I39727324e82fcfd15b3b242c53ed5534e2e5511d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372912
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78520}
The register state is accessed a lot in the mid-tier register allocator.
Instead of going through an accessor with a DCHECK, just access
directly. This makes stepping for debugging a lot easier, and will
result in an easy-to-debug nullptr access if the register state is not
initialized.
R=thibaudm@chromium.org
Bug: v8:12330
Change-Id: Icf4d1cc187a34f28ee44fc9b80ee5d765aa14b9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372911
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78516}
The bailout is there explicitly in the code, so we should allow it in
{CheckBailoutAllowed}.
R=ahaas@chromium.org
Bug: v8:12527
Change-Id: Ifd906afb5f034f05c2bf7d9a28e3ab458549e7ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372915
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78515}
Spilling was already fixed if a fixed SIMD register overlaps with an
allocated FP register, but the other way around was missing: If an odd
FP register (in this case d1) is used as a fixed output register, but
this register is in use as the upper half of a SIMD register (in this
case q0), we did not detect this and would just use overwrite the SIMD
half.
This CL also fixes this case.
R=thibaudm@chromium.org
Bug: v8:12330, chromium:1284980
Change-Id: Id3f98b7accd77e38ab4cd5ff8910aaf5ad96a1ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372910
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78514}
https://crrev.com/c/3297708 changed the serialization format for typed
arrays without bumping the format version. As a consequence, builds that
include that CL fail to deserialize typed arrays serialized by previous
V8 versions.
This CL reverts the serialization format change, and does minimal test
changes to reflect the revert. https://crbug.com/v8/12532 tracks
serializing typed array flags in a backwards-compatible manner.
Bug: chromium:1284506
Change-Id: Ib32e88c6383e0ad4ad1a9ff63f413a1eb123b1ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3370408
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78507}
This reverts commit be6bd4f448.
Reason for revert: Consistent timeouts on Linux and Mac, e.g.
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20debug/37973/overviewhttps://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20-%20debug/37346/overview
Original change's description:
> [wasm] Fast paths in EvaluateInitExpression
>
> We add fast paths for the most common types of expressions in
> {EvaluateInitExpression} to improve instantiation time. We fall back to
> full expression decoding for less common operators, or for expressions
> with operands.
>
> Bug: chromium:1284557
> Change-Id: I39a1816176974058b801cdad6eaaa6da156cea04
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3367627
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78497}
Bug: chromium:1284557
Change-Id: If09468eb1e790d4359573ddff8b653fe84b0e11e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3368602
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Owners-Override: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78502}
We add fast paths for the most common types of expressions in
{EvaluateInitExpression} to improve instantiation time. We fall back to
full expression decoding for less common operators, or for expressions
with operands.
Bug: chromium:1284557
Change-Id: I39a1816176974058b801cdad6eaaa6da156cea04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3367627
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78497}
We implement loop peeling for wasm, currently available behind a flag.
Loops are peeled regardless of size.
Bug: v8:11510
Change-Id: Ia4c883abdee83df632b2611584d608c44e3295c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3367615
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78496}
Introduce a build-time flag to disable all CET shadow-stack
manipulation. This will allow us to develop the feature without breaking
production code, and enable it all at once once the feature is ready.
R=mlippautz@chromium.org
Bug: v8:12522, v8:11246, chromium:1284445, chromium:1284599
Change-Id: Iedc1b9a0c0c74f484bb76d86c84809798c0931b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3368101
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78494}
When computing the code size estimate for {PrepareAndStartCompile}, we
did not consider Liftoff code in the async path. Other invocations
checked {FLAG_liftoff} to decide whether Liftoff code will be generated.
This CL fixes the async path to do the same, and renames {uses_liftoff}
to {include_liftoff} to match the name of the parameter in
{EstimateNativeModuleCodeSize}.
R=ahaas@chromium.org
Bug: v8:12520
Change-Id: Ic92237dc05ac96ddd88c3e8788cd443c83bd446f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3367624
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78492}
The jump table sizes were added to the estimated code size, and then
again added for computing the reservation size for the code. This CL
moves the jump table size from {EstimateNativeModuleCodeSize} to
{EstimateNativeModuleMetaDataSize} so it is still considered for the
total memory associated with the {NativeModule}, but only added once for
the code space reservation.
R=ahaas@chromium.org
Bug: v8:12520
Change-Id: I871e54833659a0d466f3e8359bb3b515c85dd3cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3367622
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78491}
The V8InspectorSessionImpl constructor accepts a state, as either text
or CBOR encoded, and generally ignores all invalid inputs, except for
the case where it's a valid value, but not a dictionary value, in which
case it'll leak the value and crash upon casting to a `DictionaryValue`.
This is purely an issue with the test driver, so no security impact on
Chromium in the wild.
Fixed: chromium:1281031
Change-Id: I7b4d0aea83370499b1274d3fa214a14dc098d2f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3361838
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78490}
This method performs exactly the same operation as the official
`v8::Exception::GetStackTrace()`, which is already used in other
places, so there's no point to have a duplicate of that in the
debug interface.
Bug: chromium:1283162
Change-Id: I09dd07f678165e1565bd77173e8ce64636ef649b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366659
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78489}
Naming a class member function the same as a class name
could cause compilation issues with gcc:
```
error: changes meaning of 'StackFrameInfo' from 'class
v8::internal::StackFrameInfo'
```
This CL changes the function name to fix the problem.
Change-Id: I085018504deefefa99dbf2ff8638bc0e872fdbc8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366703
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78484}
If a fixed register is defined for an input, we did only spill the
sibling SIMD register if the other sibling was allocated. This is not
correct. If only the sibling is in use (e.g. s1 colliding with q0) we
also have to spill that sibling.
R=mslekova@chromium.org
Bug: chromium:1283042, v8:12330
Change-Id: I6a22eaf461774a0b4603ec3ff17062134a528161
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359615
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78483}
The mid-tier register allocator did not handle block merges correctly
where a SIMD register was partially overlapping with a non-SIMD
register. This CL fixes that, and reorders the code to allow for early
exits.
R=mslekova@chromium.org
Bug: chromium:1282224, v8:12330
Change-Id: I2e9275d5c1aaa764ecb63fbf8fa197b68d6b6c3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3358294
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78482}
Previously, guard regions were created by allocating pages with
PROT_NONE and relying on an allocation hint. This could fail however,
for example on Fuchsia (where it would allocate a VMO to back the guard
region) and possibly on Windows (where a placeholder mapping was
replaced by a "real" mapping).
Introducing an explicit VirtualAddressSpace::AllocateGuardRegion routine
now makes this operation more efficient and effectively guarantees that
it cannot fail if used correctly: in a regular subspace, there is no
need to allocate anything when creating guard regions since the address
space reservation backing the subspace is guaranteed to be inaccessible
when no pages are allocated in it.
Bug: chromium:1218005
Change-Id: I6945f17616b6b8dad47241af96d4cb1f660e8858
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366237
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78480}
This change fixes the implementation of the previously introduced API
`Runtime.setMaxCallStackSizeToCapture` to work correctly and also apply
(consistently) to stack traces captured by V8 when exceptions are
thrown. It does so in a fully backwards compatible manner.
This change thus makes the previous fix for catapult (which landed in
http://crrev.com/c/3347789) effective, and therefore ensures that real
world performance benchmarks aren't affected by the use of the `Runtime`
domain in the catapult test framework.
Note this is basically a reland of crrev.com/c/3361839, but without
touching the stack traces for console messages (which led to the
regressions in crbug/1283516, crbug/1283523, etc.).
Fixed: chromium:1280831
Bug: chromium:1283162, chromium:1278650, chromium:1258599
Bug: chromium:1280803, chromium:1280832, chromium:1280818
Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
Change-Id: I3dcec7b75d76ca267fac8bd6fcb2cda60d5e60dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364086
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78479}
This sprinkles some more trace events in the disabled by default
"v8.inspector" category, to help with understanding performance
impact of stack trace capturing better.
Bug: chromium:1283162
Change-Id: I6085d587f241635fbb6934bef3adc95f58c5d2aa
Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364085
Reviewed-by: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78477}
We unify the implementation of element segment expression entries with
other initializer expressions: we represent them with a {WireBytesRef}
and decode them with {InitExprInterface}. Except for reducing code
duplication, this also fixes a bug where {global.get} entries in element
segments could reference invalid globals.
Changes:
- Change {WasmElemSegment::Entry} to a union of a {WireBytesRef}
initializer expression and a {uint32_t} function index.
- In module-decoder, change parsing of expression entries to use
{consume_init_expr}. Add type checking to
{consume_element_func_index}, to complement type checking happening in
{consume_init_expr}.
- In module-instantiate.cc:
- Move instantiation of indirect tables before loading of element
segments. This way, when we call {UpdateDispatchTables} in
{SetTableEntry}, the indirect table for the current table will also
be updated.
- Consolidate table entry instantiation into {SetTableEntry}, which
handles lazily instantiated functions, or dispatches to
{WasmTableObject::Set}.
- Rename {InitializeIndirectFunctionTables} to
{InitializeNonDefaultableTables}.
- Change {InitializeNonDefaultableTables} and {LoadElemSegmentImpl}
to use {EvaluateInitExpression}.
- Add a test to exclude mutable/non-imported globals from the element
section.
- Update tests as needed.
- Update .js module emission in wasm-fuzzer-common.
Change-Id: I29c541bbca8531e8d0312ed95869c8e78a5a0c57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364082
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78476}
Chromium builds indicate that moving an optional doesn't reset the
source, and the source still indicates it has a value.
That may be a bug in base::optional, but we should fix it here first to
resolve current crashes.
Bug: chromium:1154636
Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
Change-Id: Ibfb53b6d06d5f0310e68b200cc27ca318a5a57e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366235
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78475}
The virtual register should be prefixed with a 'v' to match the printing
of virtual registers in other places.
R=mslekova@chromium.org
Bug: v8:12330
Change-Id: Ib79ace97b1c497efa3de85e1e48f5b07bb76d6cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3358293
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78474}
The mid-tier register allocator already did some consistency checks;
this CL extends them, and removes a redundant check.
The added check ensures that no two virtual registers are assigned to
the same register. A separate check for the correctness of the
{allocated_registers_bits_} bitset is folded into {CheckConsistency}.
A second check that an allocated register is contained in
{allocated_registers_bits_} is removed.
R=mslekova@chromium.org
Bug: v8:12330
Change-Id: I6420eede145f88006c49e6ab16fdbeabffb8c9c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3358291
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78473}
This fixes an unbalanced return stack that was caused by popping the
return address and jumping to it, instead of pushing it back and
returning properly.
R=leszeks@chromium.org
Bug: v8:11246
Change-Id: I5c58c587cc0f5433c0a3595f5ed4c765e90d1a30
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3365267
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78472}
See related CL for context.
Changes:
- In InitExprInterface, add the ability to evaluate function references
as index only. Remove the global buffers and use the ones passed with
the instance object instead.
- In WasmElemSegment, add a field indicating if elements should be
parsed as expressions or indices. Change module-decoder.cc to reflect
this change.
- In module-instantiate, change the signatures of LoadElemSegment,
LoadElemSegmentImpl, and EvaluateInitExpr. Move the latter out of
InstanceBuilder.
Change-Id: I1df54393b2005fba49380654bdd40429bd4869dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364081
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78470}
For low-cost exception handling, it's important to be able to quickly
drop frames from the stack until reaching the exception handler.
The Intel shadow stack offers an instruction to avoid offending
stack discipline, incsspq, which drops N values from the stack.
This CL integrates that instruction for v8 exception handling.
Bug: v8:11246
Change-Id: I908f0ab8bb3de6c36e6078e27b65132287328f2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289637
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78469}
This changes the StackFrameInfo to either hold on to a pair of
(Script,source position)
or a pair of
(SharedFunctioInfo,bytecode offset)
similar to what we do for MessageLocation. The idea here is to defer the
costly bytecode offset to source position lookup until really needed,
and in particular, avoid the costly lookup during stack trace capturing.
On the `standalone.js` benchmark in crbug.com/1283162#c1, this reduces
overall average execution time by roughly 25%, and the performance is
almost back to where it was before crrev.com/c/3302794 (being only 12%
slower than before on the `standalone.js` test case).
Note that due to unrelated limitations we cannot encode -1 as bytecode
offset in the flags field of the StackFrameInfo, and so we treat this
case specially (happens when stack trace capturing is triggered in the
function entry sequence) and just eagerly resolve it to the source
position.
Bug: chromium:1278650, chromium:1283162, chromium:1280803
Bug: chromium:1280818, chromium:1280831, chromium:1280832
Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
Change-Id: If7cf62fce48d32c0f188895d1f8c9eee51b9e70d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359633
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78466}
This is in line with PartitionAlloc's DiscardSystemPagesInternal.
When the sandbox is enabled, OS::DiscardSystemPages is used instead of
PA's version. As such, these two implementations should ideally be
mostly identical. Using MADV_FREE instead of MADV_DONTNEED as was
previously done appears to cause some memory regressions.
Bug: chromium:1276887
Change-Id: Ied92b106e9894d428e599801d753ab4c8cffd874
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364090
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78465}
Clear cached events if there is no embedder recorder.
Bug: chromium:1154636
Change-Id: I9ad3b752ea242d07b417ce3022936789c47afc6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3358292
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78464}
Int64Lowering may produce projection nodes with floating control input.
When inlining, we need to connect such nodes to the caller's start node
instead of the control dependency of the call node.
Bug: v8:12506, v8:12166
Change-Id: I1a726dc7b0ad40e98f3b745298062c2f7194288a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3352221
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78463}
This reverts commit 34f73cc759.
Reason for revert: Performance regressions throughout a lot of
system health and browsing benchmarks.
Original change's description:
> [inspector] Fix `Runtime.setMaxCallStackSizeToCapture`.
>
> This change fixes the implementation of the previously introduced API
> `Runtime.setMaxCallStackSizeToCapture` to work correctly and also apply
> (consistently) to stack traces captured by V8 when exceptions are
> thrown. It does so in a fully backwards compatible manner.
>
> This change thus makes the previous fix for catapult (which landed in
> http://crrev.com/c/3347789) effective, and therefore ensures that real
> world performance benchmarks aren't affected by the use of the `Runtime`
> domain in the catapult test framework.
>
> Bug: chromium:1283162, chromium:1278650, chromium:1258599
> Bug: chromium:1280803, chromium:1280832, chromium:1280818
> Fixed: chromium:1280831
> Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
> Change-Id: I4ec951a858317fa49096cd4023deb0104d92c9c9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3361839
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78458}
Bug: chromium:1283162, chromium:1278650, chromium:1258599
Bug: chromium:1280803, chromium:1280832, chromium:1280818
Bug: chromium:1280831
Change-Id: Id1efaffa2f7f08c47f833f68b8a297494edee21e
Fixed: chromium:1283751, chromium:1283749, chromium:1283746
Fixed: chromium:1283729, chromium:1283700, chromium:1283700
Fixed: chromium:1283691, chromium:1283687, chromium:1283678
Fixed: chromium:1283677, chromium:1283676, chromium:1283675
Fixed: chromium:1283674, chromium:1283618, chromium:1283536
Fixed: chromium:1283523, chromium:1283516
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364078
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78462}
This change fixes the implementation of the previously introduced API
`Runtime.setMaxCallStackSizeToCapture` to work correctly and also apply
(consistently) to stack traces captured by V8 when exceptions are
thrown. It does so in a fully backwards compatible manner.
This change thus makes the previous fix for catapult (which landed in
http://crrev.com/c/3347789) effective, and therefore ensures that real
world performance benchmarks aren't affected by the use of the `Runtime`
domain in the catapult test framework.
Bug: chromium:1283162, chromium:1278650, chromium:1258599
Bug: chromium:1280803, chromium:1280832, chromium:1280818
Fixed: chromium:1280831
Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
Change-Id: I4ec951a858317fa49096cd4023deb0104d92c9c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3361839
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78458}
The `Console` domain has been deprecated (in favor of `Log` and
`Runtime`) since over four years now, and its use is strongly
discouraged.
However, making `Runtime.setMaxCallStackSizeToCapture` useful (in
light of the refactorings for crbug.com/1283162) and more correct
(wrt. to the anticipated behavior), would be complicated seriously
if we also need to worry about `Console` domain interference.
So this CL simply removes the feature that `Console.enable` turns
on stack trace capturing for error and message objects, and won't
send `line`, `column`, and `url` with `Console.Message` events
if they aren't present on the `v8_inspector::V8ConsoleMessage`
instance (these fields have always been optional anyways).
Bug: chromium:1283162
Change-Id: I78bd1e040fe15a2372639c403bfc2f4579fd4d0c
Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3361837
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78454}
The v8-debug.h and its implementations in api.cc are effectively owned
by the DevTools team.
Bug: none
Change-Id: I0eacb901bad771fca9aff19ded6bde0c34753174
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3361835
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78453}
This introduces a new `GetLocation()` method for `v8::StackFrame`s,
which returns both line and column number at the same time (using the
existing `v8::Location` class). Since `v8::StackFrame` instances store
only the source position (per https://bit.ly/v8-stack-frame), we
currently need to look up the source position in the Script's line table
twice, once when we request the line number, and another time when we
request the column number.
With `GetLocation()` we perform only a single lookup in the Script's
line table and return both line and column number at the same time. This
cuts roughly 8% of the average execution time from the `standalone.js`
benchmark mentioned in crbug.com/1280519.
Bug: chromium:1280519, chromium:1278650, chromium:1069425
Bug: chromium:1077657, chromium:1283162
Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
Change-Id: Ia3a0502990b6230363112a358b59875283399404
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359628
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78452}
Previously the `Debugger.CallFrame`s in `Debugger.paused` events would
report locations relative to the surrounding document in case of inline
scripts with `//@ sourceURL` annotations (while `Runtime.CallFrame` was
already fixed previously as part of crrev.com/c/3069289). With this CL
the locations in `Debugger.CallFrame` are also appropriately adjusted.
Drive-by-fix: Several inspector tests were (incorrectly) relying on this
wrong treatment, and were also unnecessarily using //# sourceURL
annotations. So part of this CL also addresses that problem and makes
the tests more robust, using addInlineScript() helper.
Fixed: chromium:1283049
Bug: chromium:1183990, chromium:578269
Change-Id: I6e3b215d951c3453c0a9cfc9bccf3dc3d5e92fd6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359619
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78450}
On concurrent threads, CppMarkingState allocates its own
cppgc::internal::MarkingStateBase.
On the mutator thread, CppMarkingState reuses the same MarkingStateBase
as CppHeap's mutator thread visitor.
That means the mutator thread doesn't need to rely on publishing
segments to push object from V8 to CppHeap.
Bug: v8:12407
Change-Id: I161adf8dcdc9aa960de65b47feb2abd3b605df7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295454
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78449}
Included in this CL:
(*) Introduce CppMarkingState that V8 should use to push references to
Oilpan. CppMarkingState allocates its own Worklist::Locals to
support concurrent updates from V8.
(*) Split Oilpan MarkingWorklist object to form a base class used by
CppMarkingState.
(*) Remove MarkerFactory and split marking initialization. Marking
worklists should already be initialized when V8 initializes
visitors. For incremental marking, this requires splitting
marking initialization and marking start.
(*) Drive-by: Mark JSObject::IsApiWrapper and
JSObject::IsDroppableApiWrapper as const.
Bug: v8:12407
Change-Id: I35cc816343da86f69a68306204675720e9b3913f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293410
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78446}
This CL splits the TF type for JSFunction into CallableFunction and
ClassConstructor. This differentiation allows us to lower calls to the
CallFunction Builtin only for functions that we can actually call.
Class Constructors are special, as they are callable but should raise
an exception if called.
By not lowering class constructors to calls to CallFunction (but the
more generall Call) builtin, we can remove the checks for class
constructors from CallFunction (in a follow-up CL).
Bug: chromium:1262750
Change-Id: I399967eb03b2f20d2dcb67aef2243b32c9d3174e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3350457
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78445}
Wasm values are stored in memory in little endian order even
on BE machines and as a result they need to be manually reversed
after a load.
Other such atomic ops get patched during Wasm compilation or
during code-gen, this is one of the few places where a runtime call is
made to C++ which requires this fix.
As the the runtime stub is used on both TurboFan and Liftoff this
patch will fix both cases.
Up until now the cctest was passing incorrectly as it's mixing the
Wasm memory buffer with TypedArrays. TypedArrays don't have the
LE enforcement and use the native byte order.
With this patch the test is now failing as expected
and is being skipped for now.
Bug: v8:12505
Change-Id: I49fac208f1fab7396b7d9911e803bc047b3b8263
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3350744
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78433}
This updates the following set of console builtins in V8 to match the
Console Standard (https://console.spec.whatwg.org) with respect to
(potentially side effecting) type conversions:
- console.debug
- console.error
- console.info
- console.log
- console.trace
- console.warn
- console.group
- console.groupCollapsed
- console.assert
The V8 implementation only performs the type conversions and updates
the arguments in-place with the results from the %String% constructor,
%parseInt%, or %parseFloat% invocations. The actual formatting is
still left completely to the debugger front-end.
To give a concrete example, the following code
```js
const msgFmt = {
toString() { return 'Message %i' }
};
console.log('LOG: %s`, msgFmt, 42);
```
sends the following parameters to the debugger front-end
```js
["LOG: %s", "Message %i", 42]
```
and it's then the job of the front-end to perform the actual string
substitutions.
It's also worth calling out that the console builtins are only
concerned with %s, %f, %d, and %i formatting specifiers, since
these are the only ones that trigger type conversions, and %o, %O,
and %c can only be implemented in a meaningful way at a higher
level.
Fixed: chromium:1277944
Bug: chromium:1282076
Doc: https://bit.ly/v8-proper-console-type-conversions
Spec: https://console.spec.whatwg.org
Change-Id: I0996680811aa96236bd0d879e4a11101629ef1a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3352118
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78432}
Private method loads are compiled to a named load of a private brand,
which always loads a BlockContext. This BlockContext holds the private
methods common to all instances of a class. TurboFan currently considers
JSLoadNamed to be of Type::NonInternal(). Private methods break this
assumption, since BlockContext is of Type::OtherInternal().
This CL changes the typing of JSLoadNamed of private brands to be
Type::OtherInternal().
Bug: v8:12500
Change-Id: I91f39747bf9422bd419d299f44152f567d8be8db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3351167
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78431}
... in order to ease issues debugging.
Bug: chromium:1241665
Change-Id: I7731a37e642acd0aef02570fb70faf0bc65495ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3353367
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78430}
