Skip to content

V
V8
Switch branch/tag
  1. 09 Dec, 2021 9 commits
    • Toon Verwaest's avatar
      Reland [json] Set options to share on JSON.parse error script · b8dae132
      Toon Verwaest authored 
      This ensures that the unhandledrejection callback fires.

Bug: chromium:1219363
Change-Id: I367d9a90132443e8ec94c1db380b9ef3160625c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3326242Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78321}
      b8dae132
    • Benedikt Meurer's avatar
      [stack-traces] Don't hold on to code objects from StackFrameInfos. · 6b1fb003
      Benedikt Meurer authored 
      Previously every `StackFrameInfo` instance would maintain a reference to
an AbstractCode object, which was used to resolve the `code_offset` on
that stack frame. However, it turns out that nowadays this is not
necessary anymore, since all `code_offset`s reported for JavaScript
frames are already bytecode offsets and thus can be resolved by just
looking at the functions' bytecode.

For WebAssembly frames we will also eagerly resolve the `code_offset`
(which is different depending on whether we're looking at Liftoff or
TurboFan code) to the byte offset (relative to the function start) and
stash that away in the `StackFrameInfo`.

For builtin exit frames, the `abstract_code` on the function always
refers to the builtin code object and thus, there's no point in keeping
an extra pointer to it around on the `StackFrameInfo`.

This way the `StackFrameInfo` representation is somewhat uniform, and
more importantly, the `StackFrameInfo` instances will no longer need to
hold to concrete code objects.

Drive-by-fix: Use `FixedArray::SetAndGrow()` when adding to the elements
in the `StackTraceBuilder`.

Also-By: szuend@chromium.org, jarin@chromium.org
Bug: chromium:1258599, chromium:1077657, v8:8742, chromium:1069425
Change-Id: I650e400e0e1acd920281669bdc7b5e1199683ae8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3323073Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78320}
      6b1fb003
    • Thibaud Michaud's avatar
      [wasm] Fix wasm stack segment iterator · a8d4ff7d
      Thibaud Michaud authored 
      Only initialize the superclass fields initially. The constructor was
using an overload of the same class's constructor instead. In most cases
this still behaved as expected because the {frame_} field would be
overwritten with the right value inside the constructor. But when the
stack segment is empty we would keep the wrong value from the
ThreadLocalTop info instead of {nullptr}.

R=jkummerow@chromium.org

Bug: v8:12191, v8:12485
Change-Id: Iff6a7ea7c8501deaee9ac9f95cd066d965ddbe09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3326241Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78319}
      a8d4ff7d
    • Camillo Bruni's avatar
      [api] Add LongTaskStats::v8_execute_us · ce02d2f4
      Camillo Bruni authored 
      The execute_us is now tied to the --slow-histograms flag.
This currently enabled on a small population as a persistent finch study
which should give us enough coverage for now.

Drive-by-fixes:
- Rename counter: execute_precise() to execute()
- Avoid Leave/Enter overhead in NestedTimedHistogramScope if the
  histogram is not enabled
- Only stop timers in debug mode for NestedTimedHistogramScope

Bug: chromium:1275056
Change-Id: Id6a492bdd68edb5194cb191c7083829a9f90283f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320431Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78318}
      ce02d2f4
    • Marja Hölttä's avatar
      [rab / gsab] Add RAB / GSAB support to TA.p.indexOf & lastIndexOf · bd2fce57
      Marja Hölttä authored 
      Bug: v8:11111
Change-Id: I243832c05b6eb1ba2f13dc98f9b8fb177b351112
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3315438Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78317}
      bd2fce57
    • Dominik Inführ's avatar
      [handles] DCHECK that thread isn't parked when creating handles · 35ae6344
      Dominik Inführ authored 
      Parked threads are not allowed to create new handles or access the heap
in any other way. This is a pretty fundamental invariant of our
safepoint mechanism, which doesn't stop parked threads.

Change-Id: I577dbeffbb70e0843644cdc12ffbef022890c364
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3324542
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78316}
      35ae6344
    • Joyee Cheung's avatar
      Revert "[class] implement reparsing of class instance member initializers" · f668e9f7
      Joyee Cheung authored 
      This reverts commit 91f08378.

Reason for revert: It's a fairly big change, and the clusterfuzz
found some bugs. Will reland with the fix after M98 branch point.

Original change's description:
> [class] implement reparsing of class instance member initializers
>
> Previously, since the source code for the synthetic class instance
> member initializer function was recorded as the span from the first
> initializer to the last initializer, there was no way to reparse the
> class and recompile the initializer function. It was working for
> most use cases because the code for the initializer function was
> generated eagarly and it was usually alive as long as the class was
> alive, so the initializer wouldn't normally be lazily parsed. This
> didn't work, however, when the class was snapshotted with
> v8::SnapshotCreator::FunctionCodeHandling::kClear,
> becuase then we needed to recompile the initializer when the class
> was instantiated. This patch implements the reparsing so that
> these classes can work with FunctionCodeHandling::kClear.
>
> This patch refactors ParserBase::ParseClassLiteral() so that we can
> reuse it for both parsing the class body normally and reparsing it
> to collect initializers. When reparsing the synthetic initializer
> function, we rewind the scanner to the beginning of the class, and
> parse the class body to collect the initializers. During the
> reparsing, field initializers are parsed with the full parser while
> methods of the class are pre-parsed.
>
> A few notable changes:
>
> - Extended the source range of the initializer function to cover the
>   entire class so that we can rewind the scanner to parse the class
>   body to collect initializers (previously, it starts from the first
>   field initializer and ends at the last initializer). This resulted
>   some expectation changes in the debugger tests, though the
>   initializers remain debuggable.
> - A temporary ClassScope is created during reparsing. After the class
>   is reparsed, we use the information from the ScopeInfo to update
>   the allocated indices of the variables in the ClassScope.
>
> Bug: v8:10704
> Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Cr-Commit-Position: refs/heads/main@{#78299}

Bug: v8:10704
Change-Id: I039cb728ebf0ada438a8f26c7d2c2547dbe3bf2d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325328
Auto-Submit: Joyee Cheung <joyee@igalia.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78315}
      f668e9f7
    • Clemens Backes's avatar
      [counters] Always provide a backing pointer · e8ea622d
      Clemens Backes authored 
      This avoids the {StatsCounter::lookup_done_} field by always
initializing the {StatsCounter::ptr_} field in {StatsCounter::GetPtr()}.
This makes the fast path for updating the counter value much simpler and
faster.

R=mlippautz@chromium.org

Bug: v8:12482
Change-Id: I89d094b15e0417bbfb302006de8eede0c200202d
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322768Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78314}
      e8ea622d
    • v8-ci-autoroll-builder's avatar
      Update google_benchmark · 76cbcce5
      v8-ci-autoroll-builder authored 
      Rolling v8/third_party/google_benchmark/src: https://chromium.googlesource.com/external/github.com/google/benchmark/+log/ab86707..1f99405

update googletest to latest release tag 1.11.0 (#1301) (Dominic Hamon)
https://chromium.googlesource.com/external/github.com/google/benchmark/+/1f99405

R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com,mlippautz@chromium.org

Change-Id: I7a16facb416071153984ccb7d81efea0578c0417
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3324589
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#78313}
      76cbcce5
  3. 08 Dec, 2021 30 commits
  5. 07 Dec, 2021 1 commit