1. 26 Jul, 2022 30 commits
  2. 25 Jul, 2022 10 commits
    • Deepti Gandluri's avatar
      Revert "[heap] Refactor methods and nested class of ConcurrentMarkingVisitor" · ad2b6a83
      Deepti Gandluri authored
      This reverts commit 6925bc09.
      
      Reason for revert: Speculative revert for roll failures: https://ci.chromium.org/ui/p/chromium/builders/try/linux_optional_gpu_tests_rel/85744/overview
      
      Original change's description:
      > [heap] Refactor methods and nested class of ConcurrentMarkingVisitor
      >
      > This CL moves a few methods and nested class SlotSnapshottingVisitor
      > from ConcurrentMarkingVisitor to ConcurrentMarkingVisitorUtility.
      >
      > Methods in ConcurrentMarkingVisitorUtility are now static and instead have a Visitor parameter.
      >
      > This is preparatory work for adding a
      > YoungGenerationConcurrentMarkingVisitor class, which will be able to
      > reuse members of ConcurrentMarkingVisitorUtility.
      >
      > Bug: v8:13012
      > Change-Id: I503c20e655578031018a2e37dd92c1d61bbe1686
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779677
      > Commit-Queue: Leon Bettscheider <bettscheider@google.com>
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#81931}
      
      Bug: v8:13012
      Change-Id: If2240b2e0769b04d752caefceb95609c6b950bb2
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787373
      Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81945}
      ad2b6a83
    • Deepti Gandluri's avatar
      Revert "cppgc: Move forward Trace(T*) deprecation" · 52bc4db6
      Deepti Gandluri authored
      This reverts commit 0609bb83.
      
      Reason for revert: Speculative revert for roll fails: https://ci.chromium.org/ui/p/chromium/builders/try/linux_optional_gpu_tests_rel/85744/overview
      
      Original change's description:
      > cppgc: Move forward Trace(T*) deprecation
      >
      > Bug: v8:13089
      > Change-Id: I271addd3a80feaa40520ab2768a2380c3d7ab62f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780821
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Anton Bikineev <bikineev@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#81939}
      
      Bug: v8:13089
      Change-Id: Ic9c0389b1b579821f089dddee7e604d81244a108
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785446
      Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
      Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
      Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#81944}
      52bc4db6
    • Deepti Gandluri's avatar
      Revert "Background merging of deserialized scripts" · 44fc1fda
      Deepti Gandluri authored
      This reverts commit e895b7af.
      
      Reason for revert: TSAN failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/8468/overview
      
      Original change's description:
      > Background merging of deserialized scripts
      >
      > Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
      > with which an embedder could request that V8 merge newly deserialized
      > script data into an existing Script from the Isolate's compilation
      > cache. This change implements those new functions. This functionality is
      > still disabled by default due to the flag
      > merge_background_deserialized_script_with_compilation_cache.
      >
      > The goal of this new functionality is to reduce memory usage when
      > multiple frames load the same script with a long delay between (long
      > enough for the script to have been evicted from Blink's in-memory cache
      > and for the top-level SharedFunctionInfo to be flushed). In that case,
      > there are two Script objects for the same script: one which was found in
      > the Isolate compilation cache (the "old" script), and one which was
      > recently deserialized (the "new" script). The new script's object graph
      > is essentially standalone: it may point to internalized strings and
      > readonly objects such as the empty feedback metadata, but otherwise
      > it is unconnected to the rest of the heap. The merging logic takes any
      > useful data from the new script's object graph and attaches it into the
      > old script's object graph, so that the new Script object and any other
      > duplicated objects can be discarded. More specifically:
      >
      > 1. If the new Script has a SharedFunctionInfo for a particular function
      >    literal, and the old Script does not, then the old Script is updated
      >    to refer to the new SharedFunctionInfo.
      > 2. If the new Script has a compiled SharedFunctionInfo for a particular
      >    function literal, and the old Script has an uncompiled
      >    SharedFunctionInfo, then the old SharedFunctionInfo is updated to
      >    point to the function_data and feedback_metadata from the new
      >    SharedFunctionInfo.
      > 3. If any used object from the new object graph points to a
      >    SharedFunctionInfo, where the old object graph contains a matching
      >    SharedFunctionInfo for the same function literal, then that pointer
      >    is updated to point to the old SharedFunctionInfo.
      >
      > The document at [0] includes diagrams showing an example merge on a very
      > small script.
      >
      > Steps 1 and 2 above are pretty simple, but step 3 requires walking a
      > possibly large set of objects, so this new API lets the embedder run
      > step 3 from a background thread. Steps 1 and 2 are performed later, on
      > the main thread.
      >
      > The next important question is: in what ways can the old script's object
      > graph be modified during the background execution of step 3, or during
      > the time after step 3 but before steps 1 and 2?
      >
      > A. SharedFunctionInfos can go from compiled to uncompiled due to
      >    flushing. This is okay; the worst outcome is that the function would
      >    need to be compiled again later. Such a risk is already present,
      >    since V8 doesn't keep IsCompiledScopes for every compiled function in
      >    a background-deserialized script.
      > B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
      >    compilation. This is also okay; the merge completion logic on the
      >    main thread will just keep this lazily compiled data rather than
      >    inserting compiled data from the newly deserialized object graph.
      > C. SharedFunctionInfos can be cleared from the Script's weak array if
      >    they are no longer referenced. This is mostly okay, because any
      >    SharedFunctionInfo that is needed by the background merge is strongly
      >    referenced and therefore can't be cleared. The only problem arises if
      >    the top-level SharedFunctionInfo gets cleared, so the merge task must
      >    deliberately keep a reference to that one.
      > D. SharedFunctionInfos can be created if they are needed due to lazy
      >    compilation of a parent function. This change is somewhat troublesome
      >    because it invalidates the background thread's work and requires a
      >    re-traversal on the main thread to update any pointers that should
      >    point to this lazily compiled SharedFunctionInfo.
      >
      > At a high level, this change implements three previously unimplemented
      > functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
      >
      > - BackgroundDeserializeTask::SourceTextAvailable, run on the main
      >   thread, checks whether there is a matching Script in the Isolate
      >   compilation cache which doesn't already have a top-level
      >   SharedFunctionInfo. If so, it saves that Script in a persistent
      >   handle.
      > - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
      >   whether the persistent handle from the first step exists (a fast
      >   operation which can be called from any thread).
      > - BackgroundDeserializeTask::MergeWithExistingScript, run on a
      >   background thread, performs step 3 of the merge described above and
      >   generates lists of persistent data describing how the main thread can
      >   complete the merge.
      > - BackgroundDeserializeTask::Finish is updated to perform the merge
      >   steps 1 and 2 listed above, as well as a possible re-traversal of the
      >   graph if required due to newly created SharedFunctionInfos in the old
      >   Script.
      >
      > The merge logic has nothing to do with deserialization, and indeed I
      > hope to reuse it for background compilation tasks as well, so it is all
      > contained within a new class BackgroundMergeTask (in compiler.h,cc). It
      > uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
      > the object visitation that updates pointers to SharedFunctionInfos.
      >
      > [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
      >
      > Bug: v8:12808
      > Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/main@{#81941}
      
      Bug: v8:12808
      Change-Id: I82a080e6287828445293cb6b4b94a5e8f15eb8f3
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787213
      Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#81943}
      44fc1fda
    • Frank Tang's avatar
    • Seth Brenith's avatar
      Background merging of deserialized scripts · e895b7af
      Seth Brenith authored
      Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
      with which an embedder could request that V8 merge newly deserialized
      script data into an existing Script from the Isolate's compilation
      cache. This change implements those new functions. This functionality is
      still disabled by default due to the flag
      merge_background_deserialized_script_with_compilation_cache.
      
      The goal of this new functionality is to reduce memory usage when
      multiple frames load the same script with a long delay between (long
      enough for the script to have been evicted from Blink's in-memory cache
      and for the top-level SharedFunctionInfo to be flushed). In that case,
      there are two Script objects for the same script: one which was found in
      the Isolate compilation cache (the "old" script), and one which was
      recently deserialized (the "new" script). The new script's object graph
      is essentially standalone: it may point to internalized strings and
      readonly objects such as the empty feedback metadata, but otherwise
      it is unconnected to the rest of the heap. The merging logic takes any
      useful data from the new script's object graph and attaches it into the
      old script's object graph, so that the new Script object and any other
      duplicated objects can be discarded. More specifically:
      
      1. If the new Script has a SharedFunctionInfo for a particular function
         literal, and the old Script does not, then the old Script is updated
         to refer to the new SharedFunctionInfo.
      2. If the new Script has a compiled SharedFunctionInfo for a particular
         function literal, and the old Script has an uncompiled
         SharedFunctionInfo, then the old SharedFunctionInfo is updated to
         point to the function_data and feedback_metadata from the new
         SharedFunctionInfo.
      3. If any used object from the new object graph points to a
         SharedFunctionInfo, where the old object graph contains a matching
         SharedFunctionInfo for the same function literal, then that pointer
         is updated to point to the old SharedFunctionInfo.
      
      The document at [0] includes diagrams showing an example merge on a very
      small script.
      
      Steps 1 and 2 above are pretty simple, but step 3 requires walking a
      possibly large set of objects, so this new API lets the embedder run
      step 3 from a background thread. Steps 1 and 2 are performed later, on
      the main thread.
      
      The next important question is: in what ways can the old script's object
      graph be modified during the background execution of step 3, or during
      the time after step 3 but before steps 1 and 2?
      
      A. SharedFunctionInfos can go from compiled to uncompiled due to
         flushing. This is okay; the worst outcome is that the function would
         need to be compiled again later. Such a risk is already present,
         since V8 doesn't keep IsCompiledScopes for every compiled function in
         a background-deserialized script.
      B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
         compilation. This is also okay; the merge completion logic on the
         main thread will just keep this lazily compiled data rather than
         inserting compiled data from the newly deserialized object graph.
      C. SharedFunctionInfos can be cleared from the Script's weak array if
         they are no longer referenced. This is mostly okay, because any
         SharedFunctionInfo that is needed by the background merge is strongly
         referenced and therefore can't be cleared. The only problem arises if
         the top-level SharedFunctionInfo gets cleared, so the merge task must
         deliberately keep a reference to that one.
      D. SharedFunctionInfos can be created if they are needed due to lazy
         compilation of a parent function. This change is somewhat troublesome
         because it invalidates the background thread's work and requires a
         re-traversal on the main thread to update any pointers that should
         point to this lazily compiled SharedFunctionInfo.
      
      At a high level, this change implements three previously unimplemented
      functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
      
      - BackgroundDeserializeTask::SourceTextAvailable, run on the main
        thread, checks whether there is a matching Script in the Isolate
        compilation cache which doesn't already have a top-level
        SharedFunctionInfo. If so, it saves that Script in a persistent
        handle.
      - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
        whether the persistent handle from the first step exists (a fast
        operation which can be called from any thread).
      - BackgroundDeserializeTask::MergeWithExistingScript, run on a
        background thread, performs step 3 of the merge described above and
        generates lists of persistent data describing how the main thread can
        complete the merge.
      - BackgroundDeserializeTask::Finish is updated to perform the merge
        steps 1 and 2 listed above, as well as a possible re-traversal of the
        graph if required due to newly created SharedFunctionInfos in the old
        Script.
      
      The merge logic has nothing to do with deserialization, and indeed I
      hope to reuse it for background compilation tasks as well, so it is all
      contained within a new class BackgroundMergeTask (in compiler.h,cc). It
      uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
      the object visitation that updates pointers to SharedFunctionInfos.
      
      [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
      
      Bug: v8:12808
      Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#81941}
      e895b7af
    • Michael Achenbach's avatar
      [test] Skip flaky test · 4af62459
      Michael Achenbach authored
      No-Try: true
      Bug: v8:13107
      Change-Id: I18ed93605594c7d2baba6fb744439df0eb4cb3ba
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785146
      Auto-Submit: Michael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81940}
      4af62459
    • Michael Lippautz's avatar
      cppgc: Move forward Trace(T*) deprecation · 0609bb83
      Michael Lippautz authored
      Bug: v8:13089
      Change-Id: I271addd3a80feaa40520ab2768a2380c3d7ab62f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780821
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81939}
      0609bb83
    • Tobias Tebbi's avatar
      [builtins] add builtins PGO profiling data for x64 · 3e6ad9f2
      Tobias Tebbi authored
      Bug: v8:10470
      Change-Id: I67e1962c17caecdf7cd9e8ac64ce7e4c0d694a21
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776693Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81938}
      3e6ad9f2
    • jameslahm's avatar
      [test] Move cctest/test-api-wasm to unittests/ · e8f9ff85
      jameslahm authored
      ... api/api-wasm-unittest.
      
      Bug: v8:12781
      Change-Id: I6d6eafcbc67e114fc1fa9b1f1f8dea21ab831ee6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3748165Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: 王澳 <wangao.james@bytedance.com>
      Cr-Commit-Position: refs/heads/main@{#81937}
      e8f9ff85
    • v8-ci-autoroll-builder's avatar
      Update V8 DEPS (trusted-origins) · 7eda3f55
      v8-ci-autoroll-builder authored
      Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/be25fb2..d580717
      
      Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/a4506d5..af18ab7
      
      Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/0ca99b7..3d8d88e
      
      R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
      
      Change-Id: Idfaaa0c7c941d19b623af4f69db6b67a051f9a1e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785204
      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@{#81936}
      7eda3f55