Skip to content

V
V8
Switch branch/tag
  1. 09 Dec, 2021 3 commits
    • 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 7 commits
    • Shu-yu Guo's avatar
      [top-level-await] Consolidate module Evaluate methods · 833eba71
      Shu-yu Guo authored 
      With the TLA flag removed, EvaluateMaybeAsync is a misleading name. This
CL renamed EvaluateMaybeAsync to Evaluate and consolidate it with the
sync Evaluate method.

Bug: v8:9344
Change-Id: I376ba9b9af0ac9e40a226cc8454f042ab7d9fb50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3309233Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78282}
      833eba71
    • Corentin Pescheloche's avatar
      Reland "[profiler] Surface VM & Embedder State" · e155881f
      Corentin Pescheloche authored 
      This is a reland of 2d087f23

The changes are :
* Fix redundant reinterpret_cast in test file for MSVC failure
https://crbug.com/v8/12476
* Fix flaky test
https://crbug.com/v8/12475
If a sample is captured during a GC, no embedder context is obtained
defaulting to EMPTY. This is the expected behavior, made it in clear
in implementation and in test.
* Synchronized the embedder context filter behavior with existing
native context filter.

Original change's description:

> Add APIs to surface VMState and new EmbedderState to CpuProfile samples.
>
> EmbedderState:
> * An EmbedderState is defined as a value uint8_t and a v8::context used
> for filtering.
> * EmbedderStates are stack allocated by the embedder, construction and
> destruction set/unset the state to the isolate thread local top.
> * A v8::context is used to filter states that are added to a CpuProfile,
> if the CpuProfile do not have a ContextFilter set or if contexts do not
> match, state defaults to Empty.
>
> * v8:StateTag is already propagated all the way to a Sample, simply add
> an API to surface it.
>
> VMState:
> Change-Id: I7eed08907360b99b0ad20ddcff59c95c7076c85e
> Bug: chromium:1263871
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3188072
> Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78250}

Bug: chromium:1263871
Change-Id: Ief891b05da99c695e9fb70f94ed7ebdecc6c3b7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320037
Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78281}
      e155881f
    • Manos Koukoutos's avatar
      [wasm-gc] Introduce minimum supertype length · dc01b436
      Manos Koukoutos authored 
      We introduce a minimum length for the supertype array of gc maps. When
the depth of the rtt is known to be smaller than that length, we can
type check without bounds checking the supertype array of the object
map.

Bug: v8:7748, v8:11510
Change-Id: I88e67871040a8c4dd219e48a84527f7f3f3d0a96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312487Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78280}
      dc01b436
    • Clemens Backes's avatar
      [d8] Make counters fully atomic · 6114d098
      Clemens Backes authored 
      Counter updates were already atomic, but reading the counter values was
not. This lead to data races if one isolate called `quit` while other
isolates were still running.
This makes counters fully atomic, and reflects that by making the fields
{std::atomic<int>}.

R=mlippautz@chromium.org

Bug: v8:12481, v8:12482
Change-Id: I6fc78ad6461b93c4b3e87bec052b0a67694539e3
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/+/3320428Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78279}
      6114d098
    • Clemens Backes's avatar
      [counters] Make all counters thread-safe · f0c982b8
      Clemens Backes authored 
      D8 shares counters across isolates, so even if they are only updated
from the main thread, they need to be thread-safe.
This CL removes the distinction between {StatsCounter} and
{StatsCounterThreadSafe}, and just makes all {StatsCounter} use (cheap)
atomic operations for counter updates. This will make previously
thread-safe counters cheaper, because no Mutex is involved. It might
make previously not-thread-safe counters slightly more expensive, but
it's not expected to be a significant regression.

R=mlippautz@chromium.org

Bug: v8:12481, v8:12482
Change-Id: I47b8681c1cf26d142e1ccfafa0c192e3fdcb7d2a
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/+/3320427Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78278}
      f0c982b8
    • Patrick Thier's avatar
      Revert "[turbofan] Improve StoreStoreElimination" · 41b9cd7f
      Patrick Thier authored 
      This reverts commit 863bc2b8.

Reason for revert: https://crbug.com/1276923

Original change's description:
> [turbofan] Improve StoreStoreElimination
>
> Previously, StoreStoreElimination handled allocations as
> "can observe anything". This is pretty conservative and prohibits
> elimination of repeated double stores to the same field.
> With this CL allocations are changed to "observes initializing or
> transitioning stores".
> This way it is guaranteed that initializing stores to a freshly created
> object or stores that are part of a map transition are not eliminated
> before allocations (that can trigger GC), but allows elimination of
> non-initializing, non-transitioning, unobservable stores in the
> presence of allocations.
>
> Bug: v8:12200
> Change-Id: Ie1419696b9c8cb7c39aecf38d9f08102177b2c0f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295449
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78230}

Bug: chromium:1276923
Change-Id: I43dc3572ce1ef1fda42b7551ce8210d9f03e36ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318666
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78277}
      41b9cd7f
    • Michael Lippautz's avatar
      cppgc: Persistent: Check thread usage on slow path · 3902ffbb
      Michael Lippautz authored 
      Checks whether a Persistent is used from the creation thread on slow
path allocations. In practice, these currently happen every 256
Persistent allocations. This is a best effort check that may help to
flush out issues that are missed with DCHECK builds.

Bug: chromium:1276570
Change-Id: Ia868ca436341b1b5ef427d5b3ec04926c1394e41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318658
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78276}
      3902ffbb