Skip to content

V
V8
Switch branch/tag
  1. 13 Jan, 2022 12 commits
    • Leszek Swirski's avatar
      Revert "cppgc-js,heap: Implement snapshots for embedder fields" · 7d4e3d35
      Leszek Swirski authored 
      This reverts commit 142dd775.

Reason for revert: TSAN breaks: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/6113/overview

Original change's description:
> cppgc-js,heap: Implement snapshots for embedder fields
>
> https://crrev.com/c/3293410 added concurrent processing of C++ objects
> found through V8 embedder fields. The CL missed that those embedder
> fields are not read atomically from JS objects. The problem is that
> embedder fields are only aligned to kTaggedSize on builds with pointer
> compression and are as such mis-aligned for atomic ops. This is not a
> problem for on-heap values as the upper 32bits are anyways computed
> from the cage. Is is a problem for generic C++ values though, as they
> are used with Oilpan.
>
> This CL adds the standard marker snapshot protocol for embedder fields.
>
> Marker:
> 1. Snapshot embedder fields
> 2. Try to mark host object
> 3. On success: process snapshot
>
> Main thread:
> 1. On setting embedder fields mark the object black first
> 2. Emit a write barrier for the embedder fields
>
> This will get simpler with the heap sandbox that uses a separate table
> for embedder fields. Once the sandbox is the default configuration, we
> 	can use it as dependency for the concurrent fast path.
>
> Bug: chromium:1285706
> Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78604}

Bug: chromium:1285706
Change-Id: If1976c0356f450fc068aa4dcc39fb9a0d5417a40
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386598
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@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@{#78605}
      7d4e3d35
    • Michael Lippautz's avatar
      cppgc-js,heap: Implement snapshots for embedder fields · 142dd775
      Michael Lippautz authored 
      https://crrev.com/c/3293410 added concurrent processing of C++ objects
found through V8 embedder fields. The CL missed that those embedder
fields are not read atomically from JS objects. The problem is that
embedder fields are only aligned to kTaggedSize on builds with pointer
compression and are as such mis-aligned for atomic ops. This is not a
problem for on-heap values as the upper 32bits are anyways computed
from the cage. Is is a problem for generic C++ values though, as they
are used with Oilpan.

This CL adds the standard marker snapshot protocol for embedder fields.

Marker:
1. Snapshot embedder fields
2. Try to mark host object
3. On success: process snapshot

Main thread:
1. On setting embedder fields mark the object black first
2. Emit a write barrier for the embedder fields

This will get simpler with the heap sandbox that uses a separate table
for embedder fields. Once the sandbox is the default configuration, we
	can use it as dependency for the concurrent fast path.

Bug: chromium:1285706
Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78604}
      142dd775
    • Seth Brenith's avatar
      [arm64] Implement jscvt feature check for Windows · 7b55fc09
      Seth Brenith authored 
      Change-Id: I7cf964294304c380fb285eebf1e65b0f84dec1a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3384233Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#78603}
      7b55fc09
    • Jochen Eisinger's avatar
      Drop my name from V8 debugger TODOs · c73ab4ee
      Jochen Eisinger authored 
      I'm not going to realistically work on resolving them.

Change-Id: Idd59fe5758ab7132fa2412477242bc045b0ee02d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3378636Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Auto-Submit: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78602}
      c73ab4ee
    • Yang Guo's avatar
      Add comment to startup snapshot · e784cbd1
      Yang Guo authored 
      R=leszeks@chromium.org

Change-Id: I8e5930d9ed946ae12cad98b3456055aefcef7d18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386593
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Yang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78601}
      e784cbd1
    • Patrick Thier's avatar
      [string] Make String internalization threadsafe for shared strings · cc3c93f1
      Patrick Thier authored 
      This CL fixes 2 issues with string internalization when the string table
is shared:
1. In-place migration of a string's map to Internalized was done before
   it was sure that the string is going to be internalized (outside the
   critical section). To fix this problem StringTableKey::AsHandle() is
   now split into StringTableKey::PrepareForInsertion(), which is
   invoked outside the critical section and creates a copy if
   necessary, and StringTableKey::GetHandleForInsertion(), which is
   invoked inside the critical section only for string table misses.
   Migration of the map is handled by this method.
2. TryStringToIndexOrLookupExisting() didn't handle already internalized
   strings. So far this was impossible, as this method was only invoked
   for strings that were checked not to be internalized. However with
   a shared string table, the string could be internalized after the
   checks.

Bug: v8:12007
Change-Id: I193d6b54dc41360eee47d21cbcaa36d2652d85dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3368103Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78600}
      cc3c93f1
    • Benedikt Meurer's avatar
      [debug] Simplify async function instrumentation. · 41f0c0ba
      Benedikt Meurer authored 
      This unifies and simplifies the way we instrument async functions for
the purpose of async stack traces and async stepping. It does so while
retaining the observable behavior on the inspector level (for now).

Previously we'd mark the implicit promise of the async function object
with the async task ID, and whenever we awaited, we'd copy the async
task ID to the throwaway promise that is created by the `await`. This
however made things unnecessarily interesting in the following regards:

1. We'd see `DebugDidHandle` and `DebugWillHandle` events after the
`AsyncFunctionFinished` events, coming from the throwaway promises,
while the implicit promise is "done". This is especially confusing
with rejection propagation and requires very complex stepping logic
for async functions (after this CL it'll be possible to unify and
simplify the stepping logic).
2. We have to thread through the "can suspend" information from the
Parser all the way through AsyncFunctionReject/AsyncFunctionResolve
to the async function instrumentation to decide whether to cancel the
pending task when the async function finishes.

This CL changes the instrumentation to only happen (non recurringly) for
the throwaway promises allocated upon `await`. This solves both problems
mentioned above, and works because upon the first `await` the stack
captured for the throwaway promise will include the synchronous part as
expected, while upon later `await`s the synchronous part will be empty
and the asynchronous part will be the stack captured for the previous
throwaway promise (and the V8Debugger automatically short circuits
stacks with empty synchronous part).

Bug: chromium:1280519, chromium:1277451, chromium:1246867
Change-Id: Id604dabc19ea133ea2e9dd63181b1fc33ccb5eda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383775Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78599}
      41f0c0ba
    • jiepan's avatar
      [x64] Implement 256-bit assembler for vshufps · a54f38e1
      jiepan authored 
      Bug: v8:12228
Change-Id: I233efc9fc4636c25baba6a689f7038331fd1f32b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3303806Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Jie Pan <jie.pan@intel.com>
Cr-Commit-Position: refs/heads/main@{#78598}
      a54f38e1
    • Jakob Gruber's avatar
      [maps] Lock map_updater_access in CompleteInobjectSlackTracking · 4b8d0489
      Jakob Gruber authored 
      CompleteInobjectSlackTracking potentially shrinks multiple maps, and
the relation between these maps should be preserved in a concurrent
environment. Thus it is not enough to make each modification
atomically, but all related map modifications must be within a
critical section.

We do this by locking the map_updater_access mutex
CompleteInobjectSlackTracking, and hence moving the function to the
MapUpdater class.

Bug: chromium:1274445,v8:7990
Change-Id: If99bb8b55e03180128ee397d845fa4c269c4241e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379819Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78597}
      4b8d0489
    • v8-ci-autoroll-builder's avatar
      Update ICU · 7986c88c
      v8-ci-autoroll-builder authored 
      Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/fbc6faf..b9f6d0a

Add Latin-ASCII transliteration (Frank Tang)
https://chromium.googlesource.com/chromium/deps/icu/+/b9f6d0a

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

Change-Id: Ic00c9e3f4aa2a14a80e33f090975c73ec1169fa1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3384678
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@{#78596}
      7986c88c
    • v8-ci-autoroll-builder's avatar
      Update google_benchmark · e01f69a9
      v8-ci-autoroll-builder authored 
      Rolling v8/third_party/google_benchmark/src: https://chromium.googlesource.com/external/github.com/google/benchmark/+log/0d98dba..31e7941

Add docs for `ThreadRange`. (#1318) (Dominic Hamon)
https://chromium.googlesource.com/external/github.com/google/benchmark/+/31e7941

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

Change-Id: Iffb9cb817ddef0cf1accdcb5327d4a4ef4dc548e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3384677
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@{#78595}
      e01f69a9
    • Frank Tang's avatar
      [Temporal] Remove unnecessary -0 code · 8dfe2d41
      Frank Tang authored 
      Bug: v8:11544
Change-Id: I1f8fa01ece950addac048c5ae94d8c961666f720
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3384241Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78594}
      8dfe2d41
  3. 12 Jan, 2022 20 commits
  5. 11 Jan, 2022 8 commits