Skip to content

V
V8
Switch branch/tag
  1. 15 Jun, 2021 6 commits
  3. 14 Jun, 2021 29 commits
  5. 12 Jun, 2021 1 commit
  7. 11 Jun, 2021 4 commits
    • Igor Sheludko's avatar
      [wasm-gc] Support WasmObject elements loading in runtime · 775303f4
      Igor Sheludko authored 
      This CL adds WASM_ARRAY_ELEMENTS to distinguish WasmArray maps.

Bug: v8:11804
Change-Id: I243ce24c2f2246efbc223af14361c28506e9a2d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922884
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75109}
      775303f4
    • Zhi An Ng's avatar
      Revert "[heap] Introduce ParkedSharedMutexGuardIf and use it in compiler" · 14fda804
      Zhi An Ng authored 
      This reverts commit 4cd856ee.

Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/16843/overview

Original change's description:
> [heap] Introduce ParkedSharedMutexGuardIf and use it in compiler
>
> In some cases it could happen that the concurrent compiler tries to get
> a shared lock on a mutex that is already exclusively held by the main
> thread. The background thread will then block itself until the
> main thread leaves the critical section. If the main thread then also
> starts a GC while holding the lock, this will result in a deadlock.
>
> A GC can't start until the background thread reaches a safepoint and
> the main thread can't leave the critical section before the GC ran.
>
> This CL introduces a new version of SharedMutexGuard named
> RecursiveSharedMutexGuardIfNeeded. This class will park the thread
> when blocking is needed and will unpark the thread again as soon as
> the lock was acquired successfully. This resolves the deadlock on
> safepointing.
>
> Turbofan can then simply use that class internally for
> MapUpdaterGuardIfNeeded.
>
> Bug: v8:10315, chromium:1218318
> Change-Id: Ice04b222cc979e4905791118caede26e71fca6de
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953288
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75107}

Bug: v8:10315
Bug: chromium:1218318
Change-Id: Ied5d8d8f3e4c7e036a5a42a25c43e8ca1ecc1218
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2956698
Auto-Submit: Zhi An Ng <zhin@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/master@{#75108}
      14fda804
    • Dominik Inführ's avatar
      [heap] Introduce ParkedSharedMutexGuardIf and use it in compiler · 4cd856ee
      Dominik Inführ authored 
      In some cases it could happen that the concurrent compiler tries to get
a shared lock on a mutex that is already exclusively held by the main
thread. The background thread will then block itself until the
main thread leaves the critical section. If the main thread then also
starts a GC while holding the lock, this will result in a deadlock.

A GC can't start until the background thread reaches a safepoint and
the main thread can't leave the critical section before the GC ran.

This CL introduces a new version of SharedMutexGuard named
RecursiveSharedMutexGuardIfNeeded. This class will park the thread
when blocking is needed and will unpark the thread again as soon as
the lock was acquired successfully. This resolves the deadlock on
safepointing.

Turbofan can then simply use that class internally for
MapUpdaterGuardIfNeeded.

Bug: v8:10315, chromium:1218318
Change-Id: Ice04b222cc979e4905791118caede26e71fca6de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953288
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75107}
      4cd856ee
    • Michael Achenbach's avatar
      Revert "[no-wasm] Exclude trap-handler implementation" · ce9cc71c
      Michael Achenbach authored 
      This reverts commit 5d84b6cb.

Reason for revert: Breaks mac-arm64:
https://ci.chromium.org/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release/4636
https://chromium-swarm.appspot.com/task?id=5414a227cc3d6b10

Original change's description:
> [no-wasm] Exclude trap-handler implementation
>
> The trap handler is only needed for WebAssembly, hence it can be
> excluded in no-wasm builds (v8_enable_webassembly = false).
> This makes it easier to port WebAssembly to platforms that do not need
> to support WebAssembly.
>
> R=​ahaas@chromium.org, jkummerow@chromium.org
> CC=​johnx@google.com
>
> Bug: v8:11877
> Change-Id: I25c34c2c4f1122227047e13add532ee2b9f73d2f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953285
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75101}

Bug: v8:11877
Change-Id: I7a98341f6c03667c6400dced2bc69746011dd3d4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2956868
Auto-Submit: Michael Achenbach <machenbach@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/master@{#75106}
      ce9cc71c