1. 10 Dec, 2021 9 commits
  2. 09 Dec, 2021 17 commits
    • Michael Lippautz's avatar
      cppgc: Advance deprecation arounds write barrier · 3afcbf5c
      Michael Lippautz authored
      Advance deprecations and remove fully deprecated code.
      
      Bug: v8:12165
      Change-Id: I2cf1715d6878ff65e5b9beaddb8df7aec780b21e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328781
      Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
      Commit-Queue: Anton Bikineev <bikineev@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78329}
      3afcbf5c
    • Dominik Inführ's avatar
      Revert "[heap] Optimize time to reach global safepoint" · b51a100d
      Dominik Inführ authored
      This reverts commit 86038ecf.
      
      Reason for revert: Caused TSAN failures
      
      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: I32ef7139d4392adfadeffeb70c06f3ed18109ca8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328782
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78328}
      b51a100d
    • Omer Katz's avatar
      cppgc: Reflush in construction objects after parallel marking · 529b8d3c
      Omer Katz authored
      Concurrent marking could still push object to the in construction
      worklist after it is emptied at the start of the atomic pause.
      
      Bug: v8:12479
      Change-Id: I539e5857001c4689867a3de6adb11142f639cb5b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3327143Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78327}
      529b8d3c
    • Manos Koukoutos's avatar
      [wasm][turbofan] Refactor/improve global operations · 2b985fb8
      Manos Koukoutos authored
      Changes:
      - Refactor all global base and offset computations into a single
        function and simplify GlobalGet and GlobalSet.
      - Remove unneeded pointer arithmetic in the simd case. This enables the
        use of object operators, including LoadImmutableFromObject, which
        might enable more loads to be eliminated.
      
      Bug: v8:11510
      
      Change-Id: Ieab45fd9433863780bcfd6d4596786c08e3951a6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320457Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78326}
      2b985fb8
    • Manos Koukoutos's avatar
      [wasm][turbofan] Immutable object operators · 4113cf64
      Manos Koukoutos authored
      Design doc: bit.ly/36MfD6Y
      
      We introduce simplified operators LoadImmutableFromObject and
      InitializeImmutableInObject. These are lowered to Loads and Stores like
      LoadFromObject and StoreToObject.
      We split CsaLoadElimination::AbstractState in two HalfStates,
      which represent the mutable and immutable component of the state.
      Immutable operators in the effect chain modify the immutable half-state,
      and plain operators modify the mutable half-state. The immutable part is
      maintained through write effects and loop headers. Immutable
      initializations do not lookup and kill previous overlapping stores,
      assuming each offset cannot be initialized more than once.
      
      Bug: v8:11510
      
      Change-Id: I0f5feca3354fdd3bdc1f511cc5214ec51e1407ad
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268728Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78325}
      4113cf64
    • V8 Autoroll's avatar
      Version 9.9.0 · 002e39e9
      V8 Autoroll authored
      Change-Id: I3e803b880574fa17b276f8f3e3e78198a2920866
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3326439Reviewed-by: 's avatarLutz Vahl <vahl@chromium.org>
      Commit-Queue: Liviu Rau <liviurau@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78324}
      002e39e9
    • Maya Lekova's avatar
      Revert "[stack-traces] Don't hold on to code objects from StackFrameInfos." · 3ea957a6
      Maya Lekova authored
      This reverts commit 6b1fb003.
      
      Reason for revert: breaks gc stress bots - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/36626/overview
      
      Original change's description:
      > [stack-traces] Don't hold on to code objects from StackFrameInfos.
      >
      > 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/+/3323073
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78320}
      
      Bug: chromium:1258599, chromium:1077657, v8:8742, chromium:1069425
      Change-Id: I20643ad8f0c383b754841fc52f9b3447b004c9d0
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3327141
      Auto-Submit: Maya Lekova <mslekova@chromium.org>
      Owners-Override: Maya Lekova <mslekova@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@{#78323}
      3ea957a6
    • Yu Liu's avatar
      Revert "[loong64][mips64][fastcall] Enable float support on loong64 · 6ab842f8
      Yu Liu authored
       and mips64"
      
      This reverts commit 1d6dc2b9.
      
      Reason for revert: this modify is inconsistent with the allocation
      method of the parameter register on the real machine on loong64.
      
      Original change's description:
      > [loong64][mips64][fastcall] Enable float support on loong64 and mips64
      >
      > Port commit 098f31f4
      >
      > Bug: chromium:1052746
      >
      > Change-Id: I4f9fd952c2ce8b51772eac89d4852d55363d1ed1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3292352
      > Auto-Submit: Liu yu <liuyu@loongson.cn>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78106}
      
      Bug: chromium:1052746
      Change-Id: I392f5634cf7ddf208fa9effd32d4ffff941f6179
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3324343Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Yu Liu <liuyu@loongson.cn>
      Cr-Commit-Position: refs/heads/main@{#78322}
      6ab842f8
    • 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 14 commits
    • Shu-yu Guo's avatar
      [object] Add Object::Relaxed_ReadField · 86ebfc96
      Shu-yu Guo authored
      This method has no users in this CL and is a pre-requisite for shared
      strings.
      
      Bug: v8:12007
      Change-Id: Id8eaf58aa8bb3092c710279c0c9ae0eda5581284
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3321564Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78312}
      86ebfc96
    • Shu-yu Guo's avatar
      Revert "[wasm] Add --wasm-dynamic-tiering to --future" · 780d9b88
      Shu-yu Guo authored
      This reverts commit cb9e8608.
      
      Reason for revert: Causing timeouts on Wasm tests on TSAN and
      also seems to cause some deadlock issue on shared isolate GC:
      https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20no-concurrent-marking/6847/overview
      
      Original change's description:
      > [wasm] Add --wasm-dynamic-tiering to --future
      >
      > R=​jkummerow@chromium.org
      >
      > Bug: v8:12281
      > Change-Id: Ic1a2534aef4b6335c068636ee4e3aa10300fca53
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322767
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Commit-Queue: Andreas Haas <ahaas@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78309}
      
      Bug: v8:12281
      Change-Id: Idf2bea0907daea645be922f0db776caa9dff07a3
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325023
      Auto-Submit: Shu-yu Guo <syg@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@{#78311}
      780d9b88
    • Shu-yu Guo's avatar
      Revert "[json] Set options to share on JSON.parse error script" · 48261cd8
      Shu-yu Guo authored
      This reverts commit 67a59d80.
      
      Reason for revert: Breaking JSON module web tests:
      https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Blink%20Linux/15211/overview
      
      Original change's description:
      > [json] Set options to share on JSON.parse error script
      >
      > This ensures that the unhandledrejection callback fires.
      >
      > Bug: chromium:1219363
      > Change-Id: I184a728105863f9e207a603f2d45e26393c98796
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322978
      > Auto-Submit: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78306}
      
      Bug: chromium:1219363
      Change-Id: I2be149b4fcac026dfb9a70b941cf1ff10a8747a1
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3324387
      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@{#78310}
      48261cd8
    • Andreas Haas's avatar
      [wasm] Add --wasm-dynamic-tiering to --future · cb9e8608
      Andreas Haas authored
      R=jkummerow@chromium.org
      
      Bug: v8:12281
      Change-Id: Ic1a2534aef4b6335c068636ee4e3aa10300fca53
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322767Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78309}
      cb9e8608
    • Dominik Inführ's avatar
      [heap] Optimize time to reach global safepoint · 86038ecf
      Dominik Inführ authored
      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/+/3310910Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78308}
      86038ecf
    • Leszek Swirski's avatar
      [compiler-dispatcher] Delete Jobs as BG work · 85877e54
      Leszek Swirski authored
      Deleting / deallocating Jobs, along with everything they own (e.g.
      PersistentHandles), can take a long time, especially if the allocator
      isn't too friendly to deallocating on a different thread than where the
      allocation happened.
      
      Instead, enqueue Jobs for deletion as part of background processing,
      with the hope that they end up being deallocated on the same thread as
      they were allocated, and at the very least taking the deallocation time
      off the main thread. The deletion queue is processed after the pending
      background jobs are all processed, and counts as a single "background
      job" as far as parallelism is concerned.
      
      Bug: chromium:1275157
      Change-Id: Ie7c3f725f7e510b4325e7590e60477338c478388
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314835Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78307}
      85877e54
    • Toon Verwaest's avatar
      [json] Set options to share on JSON.parse error script · 67a59d80
      Toon Verwaest authored
      This ensures that the unhandledrejection callback fires.
      
      Bug: chromium:1219363
      Change-Id: I184a728105863f9e207a603f2d45e26393c98796
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322978
      Auto-Submit: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78306}
      67a59d80
    • Leszek Swirski's avatar
      [compiler] Use SmallVector for Parser->BG thread use counts · ffdc50a9
      Leszek Swirski authored
      Change the off-thread parse to fill a SmallVector<UseCounterFeature, 8>
      on the BG compile task, rather than an int[kUseCounterFeatureCount]
      array. This allows us to keep the loop over use counts in the compile
      task finalization short by avoiding looping over unused counters.
      
      The value 8 was chosen as a "reasonable small number"; experimenting on
      our benchmarks shows a max of 3 use counts collected per compile (and
      at a vanishingly low percentage of all compiles).
      
      Passing around an explicit SmallVector<UseCounterFeature, 8> pointer,
      complete with size, is a bit ugly, but since it's used only in this one
      place (Parser -> BackgroundCompileTask) I can live with it to avoid
      further indirections. Typedeffing it is possible, but it's not clear
      where, since it's needed in both src/codegen/compiler.h and
      src/parsing/parser.h, and neither includes the other.
      
      Change-Id: Idb73e2f56fa9e8911ea29fb810d7562246f19d46
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318662Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78305}
      ffdc50a9
    • Andreas Haas's avatar
      [wasm] Add priority to V8's --wasm-dynamic-tiering · ef14030b
      Andreas Haas authored
      With the existing code, V8's --wasm-dynamic-tiering flag gets ignored
      in Chrome, because a Chrome flag would override it. With this CL,
      the flag --wasm-dynamic-tiering can be used to enable dynamic tiering
      explicitly.
      
      R=jkummerow@chromium.org
      
      Bug: v8:12281
      Change-Id: I83b8417527872a1a920fcb543932915caf1ed754
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322766Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78304}
      ef14030b
    • Milad Fa's avatar
      PPC [liftoff]: Use scratch instead of ip · 23f9d7a5
      Milad Fa authored
      scratch is already being initialized to avoid
      overwriting offset_reg. We will need to use it instead of ip.
      
      Change-Id: I4ffb93341f64dd8520e2409d6a28783738627ca2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322977Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
      Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#78303}
      23f9d7a5
    • Leszek Swirski's avatar
      [compiler-dispatcher] Move Job pointer to SFI · 3b9091c8
      Leszek Swirski authored
      Reduce the enqueuing cost of compiler-dispatcher jobs by getting rid of
      the sets and hashmaps, and instead:
      
        1. Turning the pending job set into a queue, and
        2. Making the SharedFunctionInfo's UncompiledData hold a pointer to
           the LazyCompilerDispatcher::Job, instead of maintaining an
           IdentityMap from one to the other.
      
      To avoid bloating all UncompiledData, this adds two new UncompiledData
      subclasses, making it four subclasses total, for with/without Preparse
      data and with/without a Job pointer. "should_parallel_compile"
      FunctionLiterals get allocated an UncompiledData with a job pointer by
      default, otherwise enqueueing a SFI without a job pointer triggers a
      reallocation of the UncompiledData to add a job pointer.
      
      Since there is no longer a set of all Jobs (aside from one for
      debug-only), we need to be careful to manually clear the Job pointer
      from the UncompiledData whenever we finish a Job (whether successfully
      or by aborting) and we have to make sure that we implicitly can reach
      all Jobs via the pending/finalizable lists, or the set of currently
      running jobs.
      
      Change-Id: I3aae78e6dfbdc74f5f7c1411de398433907b2705
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314833Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78302}
      3b9091c8
    • Marja Hölttä's avatar
      [BUILD] Add yield-processor.h to build files · 657e5dc1
      Marja Hölttä authored
      Especially bazel requires it.
      
      No-Try: true
      Change-Id: I1e9bfc705601492fff4690e76692b9271070d065
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322932Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78301}
      657e5dc1
    • Camillo Bruni's avatar
      [d8] Use explicit variable to track Worker state · 14d6d58a
      Camillo Bruni authored
      The explicit state_ variable is used to prevent undefined behaviour
      by double-joining the worker thread.
      
      Bug: chromium:1276382
      Change-Id: I338cfdb4a587eb57fec5a5a28b42371584c99102
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318669Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78300}
      14d6d58a
    • Joyee Cheung's avatar
      [class] implement reparsing of class instance member initializers · 91f08378
      Joyee Cheung authored
      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/+/2988830Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#78299}
      91f08378