This CL explicitly encodes the 'other' reason for breaking for:
* regular breakpoints
* triggered pause events.
The reason for explicitly encoding the reason is that we may otherwise
not know why we pause when we handle it. This knowledge is needed
in order to fully support instrumentation breakpoints, e.g. if we do
not know that we paused on a triggered pause, and this happens to
overlap with an instrumentation, we would previously only report
'instrumentation' as a reason which would be wrong.
Bug: chromium:1229541
Change-Id: I93c08f965a491f6d34f280157b182a78d5b3cf07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289638
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77970}
In assignments the lhs should be evaluated first and shouldn't be
re-evaluated when the value of the rhs is available. Fix it by
saving the receiver and the key registers into AssignmentLhsData
before building the assignment and use them later, instead of visiting
the AST again to retrieve the receiver.
In addition, now that we save the receiver register, use it to
perform the brand check even when we know for sure that it's
going to fail later because it's a write to a private
method or accessing the accessor in the wrong way (v8:11364),
so that the brand check error always appears first if it is present,
as specified in
https://tc39.es/proposal-private-methods/#sec-privatefieldget
Drive-by: unify the brand check error messages, and replace "Object"
with "Receiver" in the messages for clarity. The instance private
brand check now throws "Receiver must be an instance of class <name>"
and the static private brand check now throws "Receiver must be
class <name>". Also always set the expression position to the
property load position, because the brand check failure comes from
the load operation.
Bug: v8:12352, v8:11364
Change-Id: I61a8979b2e02b561dd5b2b35f9e0b6691fe07599
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3266964
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77797}
This reverts commit f9ebad0119.
Reason for revert: suspected root cause of crbug.com/1257806 Additionally, this patch might actually be incorrect as we eagerly evaluate native accessors, which can only happen if the debugger is running.
Original change's description:
> [inspector] Use side-effect free debug evaluate for inherited accessors.
>
> Replace the hard-coded blocklist ("Response.body" and "Request.body") in
> the V8 inspector with proper side-effect free debug evaluate. This is
> otherwise a non-functional change and in particular preserves the
> behavior of reporting accessors as (own) data properties. That will be
> tackled in a follow-up CL.
>
> This CL is possible because with https://crrev.com/c/3056879 Blink now
> properly marks accessors as side-effect free consistently with what the
> V8 inspector had done before.
>
> Doc: http://doc/1gLyyOlssS5zyCSEyybVC-5sp0UnNJj2hBoFyf6ryrTc
> Bug: chromium:829571, chromium:1076820, chromium:1119900
> Change-Id: Idb256accaf4cfb5db5982b3eb06ddcef588be635
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3062573
> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
> Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#76019}
Bug: chromium:829571, chromium:1076820, chromium:1119900, chromium:1257806
Fixed: chromium:1265372
Change-Id: Ia31a3022aaa9ddeae1f01eaa90e345f8bdbb21c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259653
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77708}
When evaluating a top-level expression while paused on a breakpoint, we
don't support an await expression as top-level statement. In these
cases, the error was not informative and could be improved.
To do so, we now propagate the information from DebugEvaluate to
ParseInfo and use the parse_info in parser-base to throw a more
informative error while parsing.
R=jarin@chromium.org
Fixed: chromium:1132245
Change-Id: I200c5af7391258256d1d86a09cbcae326327a0d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247037
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77587}
A test was overflowing on the progress counter when using int as type.
This CL is fixing the progress counter to use uint32_t, and re-enables
the test.
Why uint32_t instead of size_t?
In the referenced bug, the progress_counter_ (but not the
progress_total_) triggered an overflow; and since these two counters
should be relatively similar (the total count is an estimate, and can
be less than the actual progress count), we do not expect the
count to increase much more than we can already encode with int.
Bug: chromium:1246860
Change-Id: I9769884ef60d352b3787c2223e528ddf33b0b23e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3245116
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77551}
Previously having a `Symbol.toStringTag` property holding a string
somewhere in the prototype chain would always take predence over trying
to determine a reasonable name from the "constructor" (in case of
subclassing). This would lead to confusing behavior when diagnosing
objects in DevTools, for example
```js
class A extends URLSearchParams {};
new A()
```
would show `URLSearchParam` as class name for the instance rather than
`A`.
With this CL, we change the lookup logic to explicitly check for
`Symbol.toStringTag` and "constructor" along each step of the prototype
chain (skipping the "constructor" for the leaf object) and pick the
first one that yields a string (that is the function debug name in case
of "constructor").
Fixed: chromium:980018
Change-Id: Ic920b4bae02f965bc383c711f8de89c0de55fcac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3231078
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77453}
Array spread syntax `[...obj]` is compiled to a special bytecode that
tries to take fast-paths for values special kinds of `obj`s, including
Set, Map, and Array iterator instances. But these fast-paths skip the
side-effect checks of `Runtime.evaluate` and friends, and thus lead to
surprises for developers.
This CL alters the behavior to always call the `next()` builtins when
the debugger is active to make sure we catch the side effects correctly.
Fixed: chromium:1255896
Change-Id: If3fc48a119cfa791c4fde7b5c586acc22dd973e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226329
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77409}
The previous implementation would not explicitly send
`Debugger.paused` events for instrumentation breakpoints
if they were to overlap with breaks due to:
* regular breakpoints
* OOM
* exceptions
* asserts
This CL is a step towards making sure that a separate
`Debugger.paused` event is always sent for an instrumentation
breakpoint. In some cases where we have overlapping reasons
but only know of one, the 'instrumentation' reason,
we still just send out one paused event with the reason
being `instrumentation`.
Drive-by: send instrumentation notification to all sessions,
remember which breakpoints are instrumentation breakpoints
Bug: chromium:1229541, chromium:1133307
Change-Id: Ie15438f78b8b81a89c64fa291ce7ecc36ebb2182
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211892
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77333}
The logic to locate the correct function to set a breakpoint in based
on script position was treating SharedFunctionInfo::EndPosition() as
inclusive rather than exclusive. There are various assumptions all over
the Debugger that seem to demand this treatment for the toplevel script.
But it's definitely wrong for function literals.
Fixed: chromium:1253277
Change-Id: I3421703673f4d78aee28e923e03e2fca24bc06ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3197715
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77186}
Previously we'd treat %_AsyncFunctionReject (and %AsyncFunctionReject)
as side-effect free (in async functions), but that's not correct, since
promise rejections have side-effects (at the very least triggering the
unhandled promise rejection machinery in the browser).
This required a minor refactoring as previously we'd classify functions
as side-effecting or not depending on whether they contain any calls to
side-effecting intrinsics, no matter whether this call is actually
executed or not. That would break REPL mode however if we'd generally
treat all async functions with %_AsyncFunctionReject intrinsic calls as
side-effecting, so instead of performing the intrinsic checks ahead of
time, we now perform the test at execution time.
Before: https://imgur.com/5BvJP9d.png
After: https://imgur.com/10FanNr.png
Fixed: chromium:1249275
Change-Id: Ib06f945ba21f1e06ee9b13a1363fad342464fd9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3197712
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77183}
The V8 Inspector was sending an additional frame as part of async stack
traces for async functions, which pointed to the first executed `await`
in the async function. This is leaking an implementation detail of how
(and more precisely when) the inspector decides to collect this stack
trace. From the users perspective the async part of the stack trace is
supposed to capture what happened _prior to the task_ - meaning in case
of async functions: What lead to the execution of the async function.
This is reflected by the fact that the DevTools front-end (and the V8
Inspector itself) performs post-processing on these async call stacks,
removing the misleading top frame from it. But this post-processing is
not applied consistently to all async stack traces (i.e. the Console
message stack traces don't get this), and potentially also not applied
consistently across consumers of the Chromium debugger backend.
Instead the V8 Inspector now removes the top frame itself and thus
reports `await` consistently with how other async tasks are reported to
debugger front-ends.
Note: This preserves backwards compatibility with old versions of
devtools-frontend, which do post-processing (for the Call Stack) only on
async stack traces marked with "async function", while we now mark these
async stack traces with "await" instead (aligned with what the front-end
is using as user visibile string anyways in the Call Stack section, and
this matching will be updated in a separate follow up CL to look for
"await" instead of "async function").
Before: https://imgur.com/kIrWcIc.png
After: https://imgur.com/HvZGqiP
Fixed: chromium:1254259
Bug: chromium:1229662
Change-Id: I57ce051a28892177b6b96221f083ae957f967e52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3193535
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77157}
Previously the internal `[[ArrayBufferData]]` property for `ArrayBuffer`
objects reported by the inspector (and used by the DevTools front-end to
identify `ArrayBuffer`s and `WebAssembly.Memory`s using the same backing
store) simply contained a hex string representation of the backing store
pointer. However that unnecessarily leaks internal addresses and more
importantly is not deterministic, which complicates tests (just blew up
on layout tests).
This CL introduces an automatically incremented `BackingStore::id()`,
which is used instead now and is deterministic.
Bug: chromium:1199701, chromium:1163802, chromium:1249961
Change-Id: I8ee47009cd825cfdbe00230f617c87c90508ab2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162144
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76893}
EphemeronHashTable does not trigger interrupts when accessed
(as opposed to calling the WeakMapGet builtin), so it avoids
the use-after-free problem when reading exception metadata
triggers session disconnect while holding a reference
to the session.
Bug: chromium:1241860
Change-Id: I29264b04b8daf682e7c33a97faedf50e323d57c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3158326
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76864}
In a follow-up CL, the backing stores will, when the sandbox is enabled,
be referenced from V8 objects through offsets rather than raw pointers.
For that to work, all backing stores must be located inside the virtual
memory cage. This CL prepares for that.
Bug: chromium:1218005
Change-Id: Ibb989626ed7094bd4f02ca15464539f4e2bda90f
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3114136
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76486}
The v8::internal::IsolateData class in test/inspector/isolate-data.h
collides with v8::internal::IsolateData defined in
src/execution/isolate-data.h. In some circumstances, this can lead to
compilation or runtime issues. To fix that, this CL renames the class in
test/inspector to InspectorIsolateData.
Change-Id: I4b62b2a9d141169480c5a0591c1bcb2f275f87f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3116248
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76481}
This is a reland of d1b27019d3
Fixes include:
Adding missing file to bazel build
Forward-declaring classing before friend-classing them to fix win/gcc
Add missing v8-isolate.h include for vtune builds
Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}
Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit
Bug: v8:11965
Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76460}
This reverts commit d1b27019d3.
Reason for revert: Broke vtune build, tsan build and possibly others
Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}
Bug: v8:11965
Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76428}
This moves every single class/function out of include/v8.h into a
separate header in include/, which v8.h then includes so that
externally nothing appears to have changed.
Every include of v8.h from inside v8 has been changed to a more
fine-grained include.
Previously inline functions defined at the bottom of v8.h would call
private non-inline functions in the V8 class. Since that class is now
in v8-initialization.h and is rarely included (as that would create
dependency cycles), this is not possible and so those methods have been
moved out of the V8 class into the namespace v8::api_internal.
None of the previous files in include/ now #include v8.h, which means
if embedders were relying on this transitive dependency then it will
give compile failures.
v8-inspector.h does depend on v8-scripts.h for the time being to ensure
that Chrome continue to compile but that change will be reverted once
those transitive #includes in chrome are changed to include it directly.
Full design:
https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
Bug: v8:11965
Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76424}
This introduces a new, optional `nonIndexedPropertiesOnly` flag to the
`Runtime.getProperties` inspector request, which tells the inspector to
only report properties whose name is not an (typed) array index. This is
to support retrieving all properties except for the indexed ones when
the DevTools front-end decides to use the array bucketing mechanism.
Previously the DevTools front-end had some quite complicated logic in
place to simulate this via injected JavaScript, but that logic didn't
pick up internal properties and was also interfering with the inherited
accessor mechanism. With this new flag, it's straight-forward to
implement the correct behavior in the DevTools front-end.
The corresponding devtools-frontend CL is https://crrev.com/c/3099011.
Before: https://imgur.com/hMX6vaV.png
After: https://imgur.com/MGgiuJQ.png
Bug: chromium:1199701
Change-Id: Iacbe9756ed8a2e6982efaebe1e7c606d37c05379
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3099686
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76360}
Bug: v8:12008
Change-Id: I2e1d918a1370dae1e15919fbf02d69cbe48f63bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3089095
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76308}
This reverts commit a4a152ecc5.
Reason for revert: We haven't seen the flakes in a while, we can re-enable functionality
Original change's description:
> Reland "[debugger] Try to trigger pause-on-oom flakes with an extra printf"
>
> This is a reland of 8f7e915839
>
> Original change's description:
> > [debugger] Try to trigger pause-on-oom flakes with an extra printf
> >
> > We have an issue that we can't repro locally. Enable back the
> > pause-on-oom tests with an extra printf with DEBUG. We will be able to
> > better assess the failures when they appear on the bot.
> >
> > Bug: v8:10876
> > Change-Id: I066539c4b5865ecb6f2e589e9543e8c9ebd4830b
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474782
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70558}
>
> Bug: v8:10876
> Change-Id: Ice31c9455830da320ab057293c341f69e1f0c510
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484799
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70643}
Bug: v8:10876
Change-Id: I901d31e1e92bfef0b2917ea611354618e5cda585
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071404
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76302}
- Remove flag --block-concurrent-recompilation and its implementation,
including %UnblockConcurrentCompilation.
- Rewrite tests that used it in terms of the primitives introduced in
my previous CL:
https://chromium-review.googlesource.com/c/v8/v8/+/3071400/
- Remove "sync"/"no sync" arguments from %GetOptimizationStatus,
assertOptimized, etc. These are now always "no sync": they don't
do any magic.
- Remove "if %IsConcurrentRecompilationSupported then quit" from some
tests in favor of --concurrent-recompilation in their Flags line.
Bug: v8:12041, v8:7790
Change-Id: I966aae4fec85e6f9e7aeed2ba2c12e9198a3991f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3077149
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76298}
This reverts commit 91c8be9599.
RCS should not be exposed through the API or the inspector protocol as
they are meant as an internal debugging feature.
The only regularly tested and supported way is through chrome-tracing.
Given that this was used mostly for an experiment to analyse chrome's
performance, we can use pprof support as a replacement.
Original change's description:
> [DevTools] Implemented DevTools protocol API to retrieve V8 RunTime Call Stats.
>
> The new APIs are:
> enableRuntimeCallStats
> disableRuntimeCallStats
> getRuntimeCallStats
>
> The RunTime Call Stats are collected per isolate.
>
> Change-Id: I7e520e2c866288aa9f9dc74f12572abedf0d3ac8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881601
> Commit-Queue: Peter Kvitek <kvitekp@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64784}
Change-Id: Ia7575436e97d3420dd7e68414d89477e6a86bb05
Bug: v8:11395
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2998585
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76297}
Previously the V8 inspector would report native accessors, whose getter
evaluates to a value without causing a side effect, as own data
properties. But then the DevTools front-end will not be able to tell
whether that accessor was actually an own property or just an inherited
accessor.
The reason for reporting them as own properties in the first place was
to ensure that these properties show up in the object's preview. But
that we can handle differently by just marking these properties as
synthetic internally and including them in the preview.
Bug: chromium:1076820
Change-Id: I223299af7954e7b1a4a16bb5180d4ceff50f170f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094005
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76276}
Following up on https://crrev.com/c/3067319 (V8 call site) and
https://crrev.com/c/3080920 (Blink override), we can now safely remove
the formatAccessorsAsProperties() predicate in the inspector API. V8 now
consistently applies the logic to all "inherited", native accessor
properties (which means both Blink IDL attributes and V8 builtins).
Bug: chromium:1076820, chromium:1199247
Change-Id: I156ee43eb87ffd7b1ba69900fe11283f37241dda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3080568
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76187}
Adds a minimum estimated size.
Data suggests that estimated instruction size (+ relocation info size)
is linear to bytecode array length. This CL adds a constant for this
equation. The ratio remains the same.
This is important, because we want to increase success rate of
estimation when compiling on-heap.
When off-heap, we round up the assembler buffer to 4kB, so this CL
will only impact JS functions with more than 585 bytecodes, i.e, the
new added constant will be negligible.
Note: Relocation info (for Sparkplug) is usually so small that it is
not useful to have a separate zone for this.
Bug: v8:11872
Change-Id: I789e72f80b970d1f541965e7ae808b61c8174326
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069155
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76144}
So that it is possible to differentiate modules in the stack trace even
when they are anonymous.
R=kimanh@chromium.org
Bug: v8:11808
Change-Id: I12a1f07accdf62c404052f32624e9914381a7451
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3074472
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76141}
For inline scripts that have a `// #sourceURL=foo.js` annotation, the
V8 inspector (and by extension `Error.stack`) currently operates in
terms of the `foo.js`, i.e. doesn't give any hint about the actual
source, except for the line/column offsets reported upon scriptParsed.
However in case of stack frames (i.e. as part of `Error.stack` or as
part of the call frames reported via CDP), the line/column offsets are
relative to the actual source instead of relative to the `foo.js` part,
which - besides other things - makes post-processing of recorded stack
traces tricky (sometimes impossible).
This change adjusts the source positions reported for (inline) scripts
with sourceURL annotations to be relative to the (inline) script instead
of the surrounding document.
Bug: chromium:1183990
Fixed: chromium:578269
Change-Id: I74f2b93c22ec43ca796b6b51faa9df5b99cf03f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069289
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76097}
This is a reland of ce8cef36aa
Original change's description:
> [inspector] Consistently format all native accessors as own properties.
>
> Previously the V8 inspector would only turn embedder accessors on the
> prototype chain into data properties, but would not do the same for
> ECMAScript builtins, which is kind of inconsistent and weird behavior.
>
> This leaves in the hack that the inspector reports native accessor
> properties as (own) data properties, but now at least the very least
> does so consistently. In the absence of a better solution, we'll go
> with this for now.
>
> Bug: chromium:1076820, chromium:1199247
> Change-Id: I593f909a46cb714dbec629a2944eeb892881ba6f
> Before: https://imgur.com/kPuSldj.png
> After: https://imgur.com/eFau45m.png
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067319
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#76059}
Bug: chromium:1076820, chromium:1199247
Change-Id: I11987194b0d0b8b250eda4f8ce0ae5fc743eb27c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3070701
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76084}
This reverts commit ce8cef36aa.
Reason for revert: broke blink tests: https://ci.chromium.org/ui/p/chromium/builders/try/mac-rel/751822/overview
Original change's description:
> [inspector] Consistently format all native accessors as own properties.
>
> Previously the V8 inspector would only turn embedder accessors on the
> prototype chain into data properties, but would not do the same for
> ECMAScript builtins, which is kind of inconsistent and weird behavior.
>
> This leaves in the hack that the inspector reports native accessor
> properties as (own) data properties, but now at least the very least
> does so consistently. In the absence of a better solution, we'll go
> with this for now.
>
> Bug: chromium:1076820, chromium:1199247
> Change-Id: I593f909a46cb714dbec629a2944eeb892881ba6f
> Before: https://imgur.com/kPuSldj.png
> After: https://imgur.com/eFau45m.png
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067319
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#76059}
Bug: chromium:1076820, chromium:1199247
Change-Id: Ib090e0a1dad26f5c9684d906b775555b6a07cca0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069012
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76071}
Previously the V8 inspector would only turn embedder accessors on the
prototype chain into data properties, but would not do the same for
ECMAScript builtins, which is kind of inconsistent and weird behavior.
This leaves in the hack that the inspector reports native accessor
properties as (own) data properties, but now at least the very least
does so consistently. In the absence of a better solution, we'll go
with this for now.
Bug: chromium:1076820, chromium:1199247
Change-Id: I593f909a46cb714dbec629a2944eeb892881ba6f
Before: https://imgur.com/kPuSldj.png
After: https://imgur.com/eFau45m.png
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067319
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76059}
stress_flush_bytecode controls stress flushing of both bytecode and
baseline code. So rename the flag to better reflect its functionality
Bug: v8:11947
Change-Id: Ie6c124a476c3a7c6eabd1d75de030ee15fe78e32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3062567
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76043}
pthread_rwlock_t can deadlock on Mac if signals are sent to the process
in the wrong moment. Since we use processes e.g. for sampling profiling
(in both d8 and in Chrome), we hence cannot safely use pthread_rwlock_t
on Mac. Instead, fall back to a non-shared pthread_mutex_t.
Interestingly, this shows no measurable performance impact in Wasm
compilation on my MBP.
R=mlippautz@chromium.org
Bug: v8:11399
Change-Id: Ie8bfd5288bba8c4f3315ee4502b39b59d39c9bbd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060480
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76015}
The test currently fails on machines with sparkplug enabled:
```
Flag --sparkplug: value implied by --jitless conflicts
with explicit specification
```
And passes on platform without sparkplug.
Bug: chromium:1233401
Change-Id: Ia0277f8d356e34efb611ca9960c11ec78b9b94ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3058300
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75970}
R=leszeks@chromium.org
Bug: chromium:1233401
Change-Id: Ieaf7513d2dbd9bc84a996defbf0a929d35befa36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059082
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Auto-Submit: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75967}
Previously we do not tier down from baseline to interpreter, which
breaks per-bytecode side effect checks (to check whether e.g. we are
mutating a temporary object, which is not considered a side effect).
R=leszeks@chromium.org
Bug: chromium:1233401
Change-Id: Ie08b5352aa4c124421b4c9abce18326938bbc822
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056981
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75963}
This reverts commit 67960ba110.
Reason for revert:
This has been properly fixed by https://crrev.com/c/3053740.
Now dcheck_always_on already defaults to false for subprojects
like V8 and no other switch is required. The switch didn't fully
work anyways due to https://crbug.com/1231890.
Original change's description:
> Reland "[build] Add V8-specific dcheck_always_on"
>
> This is a reland of cecc666f4d
>
> Depends on:
> https://crrev.com/c/3043611
>
> Original change's description:
> > [build] Add V8-specific dcheck_always_on
> >
> > This makes the V8 dcheck control independent of Chromium's and
> > prepares switching Chromium's default behavior without affecting V8
> > developers or builders.
> >
> > Preparation for: https://crrev.com/c/2893204
> >
> > Bug: chromium:1225701
> > Change-Id: I520b96019b04196f4420716ff3500ebd6c21666f
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038528
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#75827}
>
> Bug: chromium:1225701
> Change-Id: I56568b78592addba01793d2d14f768c9ee10103d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041670
> Reviewed-by: Liviu Rau <liviurau@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75839}
Bug: chromium:1225701, chromium:1231890
Change-Id: I7e27f5774d8e162977f30f685da4b15dadcc1084
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3055294
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75935}
This properly threads through the `executionContextId` to the request
reported to the DevTools front-end, similarly to how we already report
the `executionContextId` as part of `Runtime.bindingCalled`.
Bug: chromium:1231521
Change-Id: I0a003041aedd8ec661d1b07cdddbcd1f2866a99f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3046187
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/master@{#75875}
