Drive-by refactoring: Make it evident that currently we upload additional files only for Android platform.
Bug: v8:13686
Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel
Change-Id: I8081c1185d6a92dfdcef82e697e301f3e7838dc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4205916
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Liviu Rau <liviurau@google.com>
Cr-Commit-Position: refs/heads/main@{#85592}
Per the WebIDL specification, objects that are namespaces must have the
their class string value set to their identifier name [1]. Since per
spec, console is defined as a namespace [2], console's class string must
be "console".
However, since the console object in Chromium/v8 is directly implemented
inside of v8, it doesn't adhere to the WebIDL binding norms. Its
implementation manually had its @@toStringTag set to "Object", which is
incorrect. This CL corrects it to "console" and adjusts test
expectations accordingly.
Unfortunately, this CL will have web-exposed changes to Chromium that
are not tested anywhere, specifically because console's implementation
of namespace did not adhere to the WebIDL spec. Separately,
https://crrev.com/c/4193348 fixes Chromium's web-exposed tests and
stable test expectations, to manually treat console as a namespace
(despite its broken implementation) so that the global interface listing
tests properly enumerate attributes/methods on the console object.
Once this CL lands, those expectations will need to be changed.
The motivation for this change is to ensure that all console attributes
and methods are properly accounted for in the usual Blink webexposed
stable tests that are owned by the Blink API OWNERs. This is because
recently, v8 shipped a new console method (createTask()) that entirely
bypassed the Chromium launch process:
https://www.chromium.org/blink/launching-features/, because no files
needed to be approved by Blink API OWNERs.
[1]: https://webidl.spec.whatwg.org/#ref-for-dfn-class-string%E2%91%A8
[2]: https://console.spec.whatwg.org/#console-namespace
Change-Id: I0bbd05242fc815945cce40c65d74995950d64115
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4193308
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Dominic Farolino <dom@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85572}
The patch fixes two bugs in hinting:
- trimmed whitespace in hints was not taken into account.
- range check for out-of-bound hints did not include the offset.
Bug: chromium:1409286
Change-Id: I5838cd6b697ed13a19c30f158963c0d9fac2f045
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4187224
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85448}
This will allow on the infra side to easier link to the respective
shard on a test failure. Without that it's a hassle to find out on
which shard the failing test ran.
This also simplifies how the global test_config stores information.
Some information was duplicated, but is now rather shared through
properties if the owning object is already present.
Bug: v8:13681
Change-Id: I52f01a4fac74627575d80f25923faba99eb6a1fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4181030
Reviewed-by: Liviu Rau <liviurau@google.com>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85429}
Previously in the DevTools console, users could inspect a preview of all private class members on an instance, but if they wanted to evaluate or inspect a specific private class member out of a long list, they had to be debugging and in a scope that has access to those private names.
This patch adds support for extraordinary access of out-of-scope private member access in debug-evaluate, specifically for Debugger.evaluateOnCallframe() (for console calls invoked during debugging) and Runtime.evaluate() (for console calls invoked when the user is not debugging). This kind of access is not otherwise allowed in normal execution, but in the DevTools console it makes sense to relax the rules a bit for a better developer experience.
To support this kind of extraordinary access, if the parsing_while_debugging or is_repl_mode flag is set, when we encounter a private name reference that's in a top-level scope or an eval scope under a top-level scope, instead of throwing immediately, we bind the reference to a dynamic lookup variable, and emit bytecode that calls to %GetPrivateName() or %SetPrivateName() in the runtime to perform lookup of the private name as well as the load/store operations accordingly.
If there are more than on private name on the receiver matching the description (for example, an object with two `#field` private names from different classes), we throw an error for the ambiguity (we can consider supporting selection among the conflicting private names later, for the initial support we just throw for simplicity).
If there are no matching private names, or if the found private class member does not support the desired operation (e.g. attempting to write to a read-only private accessor), we throw an error as well.
If there is exactly one matching private name, and the found private class member support the desired operation, we dispatch to the proper behavior in the runtime calls.
Doc: https://docs.google.com/document/d/1Va89BKHjCDs9RccDWhuZBb6LyRMAd6BXM3-p25oHd8I/edit
Bug: chromium:1381806
Change-Id: I7d1db709470246050d2e4c2a85b2292e63c01fe9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020267
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85421}
Creating the full call frames is expensive. The client should only
need the script id. As the script id is passed in the 'data.scriptId'
field of the message, we can omit call frames from the instrumentation
pause event.
Bug: chromium:1408105
Change-Id: I11827865168946e1f412f7d351a0d359e2ac80ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4174085
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85382}
After we received feedback about some legitmate use-cases of the
internal [[Scopes]] property, we decided to not go ahead with its
removal.
This CL removes the corresponding experimental flag.
R=kimanh@chromium.org
Bug: chromium:1365858
Change-Id: I6744889b4e2e960695838648e2f4902cbdb75890
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4154416
Auto-Submit: Simon Zünd <szuend@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85214}
This CL adds some tests for async generators to ensure that we
correctly report caught/uncaught exceptions.
Most of the cases were fixed by the for-of fix:
https://crrev.com/c/4146420
The remaining broken test cases contain a throw directly
after a `yield`. For each ".next" call we create a new promise
that we need to push on the promise stack before we actually
resume the generator.
R=bmeurer@chromium.org
Fixed: chromium:1270780
Change-Id: I8365d20490451be37cc6973d8d91aeffed7e3511
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4146421
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85196}
The bytecode generator currently uses the wrong catch prediction in
the desugaring for for-of loops. This leads to unexpected pauses in
DevTools when 'pause on uncaught exceptions' is enabled, e.g. for throwing generators.
Specifically the call to .next of the iterator is unconditionally
marked as 'uncaught' instead of using the surrounding catch
prediction. Similarly, in the desugared "finally" block we call
.return which can also throw.
Note that if both the loop body and the ".return" throws, the
exception from ".return" is caught and only the loop body exception
is re-thrown. We still pause on both throw sites since we can't
detect this case statically.
R=leszeks@chromium.org
Bug: chromium:1270780
Change-Id: I2e642ef3fbfcfc6ad19e92cf611188801ebf2450
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4146420
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85164}
We change the breakpoint hint logic to check if the script has not
locally changed (with a hash of the source text between the requested
breakpoint location and the actual breakpoint location). If the
text did not change, we set the breakpoint at the same
location as before.
Bug: chromium:1404643
Change-Id: I6ceecf9924e699aaf37518680d1cb79d3eb00959
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4138260
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85131}
Runtime.executionContextCreated provides many details in
ExecutionContextDescription structure while
Runtime.executionContextDestroyed provides only executionContextId. This
information is insufficient for the clients that use uniqueContextId.
Bug: v8:12896
Change-Id: I31df0ed618dc1c8b55c7eba8f96eeaef2d4de6c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3657439
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Vladimir Nechaev <nechaev@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85110}
The debugger utilizes the source position while single stepping
("Step-in") through the source to go from statement to statement and
skipping some expressions along the way. The debugger remembers the
"statement position" of the last stepping action.
This works well in general but falls flat for loops that only have
a single statement in them. Every step lands on the same statement,
just one loop iteration later.
We detect this case by checking if we are in the same frame and have
the exact same bytecode offset as the last step action.
Note that this also fixes "frame restarting" should we have restarted
a function while paused at the beginning of that function.
R=jarin@chromium.org
Bug: chromium:1401674
Change-Id: Id0a5753ed7cc9f23f22d869368d88e1c4b48566d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135881
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85107}
We add final types to wasm-gc.
- We introduce a `kWasmSubtypeFinalCode` as an alternative to
`kWasmSubtypeCode`.
- Behind a flag, we interpret types behind this code as final, as well
as types outside a subtype definition by default.
- For final types, type checks for call_indirect and ref.test etc. are
reduced to simple type identity checks.
Bug: v8:7748
Change-Id: Iabf147b2a15f43abc4c7d1c582f460dbdc645d66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096478
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84955}
This includes the class name of the target object as part of the
description for Proxy objects, i.e. `Proxy(HTMLElement)` for proxies
whose targets are `HTMLElement`s. This greatly improves the debugging
experience with proxies, which are becoming more common these days (for
example with Vue using proxies for their components).
Before: https://imgur.com/SbR4s6H.png
After: https://imgur.com/NWQJFj8.png
Fixed: chromium:1400253
Change-Id: I3bd2b0f91a3aeaa531d5e5dd2ca3e777e4663ba1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4109729
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84864}
Currently, any session can resume instrumentation breaks by sending
Debugger.resume command. That can lead to unreliable breakpoint
placement because sessions can resume too early.
The early resumption can happen in two ways:
- When we have two instrumented sessions, the first one to resume
can prevent the other one from setting its breakpoints
before executing the code.
- With one instrumented session and one without instrumentation
breakpoints, the uninstrumented session's Debugger.resume
command can resume the instrumentation pause before the
instrumented session can set its breakpoints.
This patch fixes both of these issues by changing the instrumentation
pause resumption logic to take note of the sessions that were notified
about the instrumentation breakpoints. The debugger will only resume
once all those sessions resume (or disconnect).
Bug: chromium:1354043
Change-Id: I84cf16b57187dbb40645b2f7ec2e08f0078539dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100466
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84827}
This patch moves the stop method from context group to session to enable
stopping each session independently. This is useful for testing that
stopping does not interact badly with other sessions.
Bug: chromium:1354043
Change-Id: I885cf49f2d4cf006fa5228edf2954099e45cfc6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100484
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84797}
Similar to the `AsyncFunctionReject` builtin, the
`AsyncGeneratorReject` should also mark the promise rejection as a
non-debuggable event.
That is because the initial throw that causes the generator rejection
downstream alreay triggered the debuggable event.
We can re-use one of the existing tests as a regression test here:
If we wait for the Runtime.evaluate promise to resolve after the first
pause, we ensure that we already paused once. The test in its current
form swallowed the second pause implicitly by disabling the debugger.
R=bmeurer@chromium.org
Bug: chromium:1270780
Change-Id: I97ab08934804fefd097e9bd01081469da5379154
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4084925
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84756}
We introduce V8InspectorSession::stop API to enable safe
detach from the session. In particular, after calling 'stop',
the session will leave any instrumentation pause it might
be in and disarm all its instrumentation breakpoints.
This is useful when the session disconnect request is registered
on V8 interrupt (so it is unsafe to disconnect at that point),
and the execution should first get to the message loop
where the disconnect can be handled safely.
Bug: chromium:1354043
Change-Id: I3caab12a21b123229835e8374efadc1f4c9954c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4085143
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84753}
This is a reland of commit 8016f5c667
Additional HandleScopes are added in 3 spots and an additional
test was added to cover the crash that caused the revert.
Adding and removing the MicrotasksCompletedCallback should be
associated with the microtask queue of the Context. We store the
context as WeakPtr and always remove the callback when it completes
regardless of the state of the debugger.
BUG=v8:13450
Change-Id: Ie4d6edcb561c6753a6d34d84cfcf4989bb6e9321
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062397
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84584}
The stack object is primarily used for conservative stack scanning, both
by the V8 and C++ garbage collectors. This CL introduces the notion of a
"stack context", which comprises of the current stack marker (the lowest
address on the stack that may contain interesting pointers) and the
values of the saved registers. It simplifies the way in which iteration
through the stack is invoked: the context must have previously been
saved and iteration always uses the stack marker.
Bug: v8:13257
Bug: v8:13493
Change-Id: Ia99ef702eb6ac67a3bcd006f0edf5e57d9975ab2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4017512
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@{#84303}
Rename the '--wasm-max-code-space' flag to
'--wasm-max-committed-code-mb'. We will introduce a new flag to set the
maximum size of a wasm code space, so the old name would be misleadingly
close to the new flag.
R=jkummerow@chromium.org
Bug: v8:13436
Change-Id: I7a86300e4f25858add1a62f9989189035ea855ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4022709
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84242}
This is a reland of commit 936b61a209
Change compared to original: Fix parameter types for CallRuntimeStub
in Liftoff.
Original change's description:
> [wasm-gc] Canonicalize JS Numbers as i31ref at the boundary
>
> JS numbers flowing into Wasm as i31ref should be canonicalized at the
> boundary. In-range numbers get canonicalized to Smis, and out-of-range
> numbers to HeapNumbers. This way, casting to i31ref, or checking for
> i31ref when casting to other types, is reduced to a Smi check.
>
> Bug: v8:7748
> Change-Id: Icd2bbca7870c094f32ddc9cba1d2be16207e80d1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008345
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84219}
Bug: v8:7748
Change-Id: I67737150252b844a296338db0c60f76b470aa43b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4022711
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84240}
Reland of https://crrev.com/c/3998633.
Each thread has its own MarkingBarrier instance for incremental
marking. A thread local variable is used to get the current thread's
instance on background threads.
However on main threads this thread local variable was always
set to nullptr. The main thread would get to its own instance through
the heap_ field in the host object's page header. This was solved this
way because setting current_marking_barrier on the main thread
seemed quite complex. Multiple isolates may be run on the same thread
and isolates may even be migrated between threads.
However, with --shared-space loading the heap_ field for a shared
object would return the main isolate's heap and we end up with
the wrong MarkingBarrier instance on client isolates. So this
CL makes main and background threads more uniform by setting the
thread local field also on the main thread. The field is set by
the already existing v8::Isolate::Scope API. Some embedders might have
to add these scopes if they don't use them properly already.
Bug: v8:13267
Change-Id: Idc257ecf6b6af09a379bdd7cd7c1d4a5e46689c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4016715
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84237}
This reverts commit 936b61a209.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20no%20pointer%20compression/2000/overview
Original change's description:
> [wasm-gc] Canonicalize JS Numbers as i31ref at the boundary
>
> JS numbers flowing into Wasm as i31ref should be canonicalized at the
> boundary. In-range numbers get canonicalized to Smis, and out-of-range
> numbers to HeapNumbers. This way, casting to i31ref, or checking for
> i31ref when casting to other types, is reduced to a Smi check.
>
> Bug: v8:7748
> Change-Id: Icd2bbca7870c094f32ddc9cba1d2be16207e80d1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008345
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84219}
Bug: v8:7748
Change-Id: Ia74e49147d230f9217ebeb2bf435d10d8f93126e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020457
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84221}
JS numbers flowing into Wasm as i31ref should be canonicalized at the
boundary. In-range numbers get canonicalized to Smis, and out-of-range
numbers to HeapNumbers. This way, casting to i31ref, or checking for
i31ref when casting to other types, is reduced to a Smi check.
Bug: v8:7748
Change-Id: Icd2bbca7870c094f32ddc9cba1d2be16207e80d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008345
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84219}
The wrapper obects for the debugger displayed e.g. in dev tools
contain a proper `null` value already.
Note: This only affects the printing of wasm tables in the test.
Change-Id: I3c2e9580b0a3983b66b9c3e2e16e5a2b322a9ff7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020261
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84201}
Use USE(), (void) is void with GCC.
Bug: chromium:1352175
Change-Id: Ic254a5d0ca2bb6d8179dfe5ba74f1d0753d456ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4022027
Commit-Queue: Adam Klein <adamk@chromium.org>
Auto-Submit: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84193}
This introduces a barrier that ensures that
`V8InspectorClient::runIfWaitingForDebugger()` is only invoked once all
sessions that requested a paused have invoked runIfWaitingForDebugger.
Downstream change: https://chromium-review.googlesource.com/c/chromium/src/+/3977348
Bug: chromium:1352175
Change-Id: I9049c2de6da8e690ad4312cd6cb799619125bb62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3976353
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84191}
This reverts commit 910def9edc.
Reason for revert: Speculative Revert https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/9800/overview
Original change's description:
> [heap] Load MarkingBarrier from thread local on main thread
>
> Each thread has its own MarkingBarrier instance for incremental
> marking. A thread local variable is used to get the current thread's
> instance on background threads.
>
> However on main threads this thread local variable was always
> set to nullptr. The main thread would get to its own instance through
> the heap_ field in the host object's page header. This was solved this
> way because setting current_marking_barrier on the main thread
> seemed quite complex. Multiple isolates may be run on the same thread
> and isolates may even be migrated between threads.
>
> However, with --shared-space loading the heap_ field for a shared
> object would return the main isolate's heap and we end up with
> the wrong MarkingBarrier instance on client isolates. So this
> CL makes main and background threads more uniform by setting the
> thread local field also on the main thread. The field is set by
> the already existing v8::Isolate::Scope API. Some embedders might have
> to add these scopes if they don't use them properly already.
>
> Bug: v8:13267
> Change-Id: Idfdaf35073d04dd5e13ad6065ef42eae3ce6a259
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3998633
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84144}
Bug: v8:13267
Change-Id: Id8493dfac03d789721ca30cd29b0dd4b67006881
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4017192
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84151}
Each thread has its own MarkingBarrier instance for incremental
marking. A thread local variable is used to get the current thread's
instance on background threads.
However on main threads this thread local variable was always
set to nullptr. The main thread would get to its own instance through
the heap_ field in the host object's page header. This was solved this
way because setting current_marking_barrier on the main thread
seemed quite complex. Multiple isolates may be run on the same thread
and isolates may even be migrated between threads.
However, with --shared-space loading the heap_ field for a shared
object would return the main isolate's heap and we end up with
the wrong MarkingBarrier instance on client isolates. So this
CL makes main and background threads more uniform by setting the
thread local field also on the main thread. The field is set by
the already existing v8::Isolate::Scope API. Some embedders might have
to add these scopes if they don't use them properly already.
Bug: v8:13267
Change-Id: Idfdaf35073d04dd5e13ad6065ef42eae3ce6a259
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3998633
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84144}
This CL adds a regression test for sloppy block function hoisting and
debug-evaluate. This was fixed in the past but the test was missing.
Fixed: chromium:1246897
Change-Id: I1d7dcbd4d95ef8e5a09f09615de017b65c3e7087
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4011039
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84141}
If a CDP client requests Debugger.pause during instrumentation pause,
the requests is currently ignored.
With this patch, the debugger will take note of a pause request during
instrumentation pause and enter the pause once the instrumentation pause
resumes.
Bug: chromium:1381967
Change-Id: I4d0337a92fa31d0666ab02b54f95aba4d89592b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008379
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84138}
This introduces a new "caught" case for Debugger.setPauseOnExceptions,
which instructs the V8 Debugger to only break on exceptions that are
predicted as caught. Previously it wasn't possible to express this with
Chrome DevTools Protocol.
Bug: chromium:1324920, chromium:1346231
Change-Id: I507cfb6058148b2e238b8f66e9720ab68cb81575
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013330
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84137}
This CL adds the regression test originally authored for
crbug.com/1085693. It no longer crashes or re-produces but we were
unable to bisect to the CL that fixed the problem since bisecting
seems to be broken.
R=bmeurer@chromium.org
Fixed: chromium:1085693
Change-Id: Iaaf2b557767a02829fc497591ed7f3623965a66c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4012718
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84108}
This CL adds "new.target" to the ScopeObject with the materialized
stack local variables. It's only available if the parser actually
allocates a variable for it, otherwise we currently throw a
ReferenceError.
The added test also ensures that "new.target" is only included for
debug-evaluate, but NOT for the scope view. Having ".new.target"
show up there would be more confusing than helpful.
Drive-by: Remove bogus DCHECK. The context we try to lookup
"new.target" can be anything, not just a `with` context.
R=bmeurer@chromium.org, leszeks@chromium.org
Bug: chromium:1246863
Change-Id: Id4f99b3336044904e3dc76912f65b6f63f092258
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4003039
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84069}
