1. 17 Aug, 2022 3 commits
  2. 16 Aug, 2022 1 commit
  3. 10 Aug, 2022 1 commit
  4. 09 Aug, 2022 1 commit
  5. 08 Aug, 2022 2 commits
    • ishell@chromium.org's avatar
      [ext-code-space] Add InterpreterEntryTrampolineForProfiling builtin · 1067c6ac
      ishell@chromium.org authored
      ... - a code range size agnostic version of InterpreterEntryTrampoline
      builtin. The new builtin is fully compatible with the default version
      and used as a template for creating interpreter entry trampoline
      Code objects when --interpreted-frames-native-stack is enabled.
      
      This CL introduces a new assembler option "position_independent_code"
      which affects the way builtin calls are generated.
      This mode is enabled only for InterpreterEntryTrampolineForProfiling.
      
      Motivation:
      
      * InterpreterEntryTrampoline uses RelocInfo::CODE_TARGET for calling
        other builtins which requires the code range to be small enough to
        allow PC-relative jumps/calls between Code objects. This is the
        reason why --interpreted-frames-native-stack was not supported on
        arm and might not work on arm64 because the code range is bigger
        than the max PC-relative distance for call/jump instructions.
        The new builtin calls other builtins via builtins entry table which
        makes the code fully relocatable and usable for any code range size.
      
      * RelocInfo::CODE_TARGET requires a target code to be materialized
        as a Code object which contradicts the Code-less builtins goal.
      
      * The --interpreted-frames-native-stack is rarely used in the wild but
        we have to pay the price of deserializing InterpreterEntryTrampoline
        builtin as a Code object which consumes address space in the code
        range and thus limits the number of V8 isolates that can be created
        because of code range exhaustion. Now the pointer compression cage
        becomes the limiting factor instead of the code range.
      
      * We can remove complicated logic of Factory::CopyCode() and respective
        support on GC side.
      
      Bug: v8:11880, v8:8713, v8:12592
      Change-Id: Ib72e28c03496c43db42f6fe46622def12e102f31
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3811287Reviewed-by: 's avatarJakob Linke <jgruber@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#82263}
      1067c6ac
    • jameslahm's avatar
      [snapshot] Dont defer ByteArray when serializing · d69c7937
      jameslahm authored
      JSTypedArray needs the base_pointer ByteArray immediately
      if it's on heap. JSTypedArray's base_pointer was initialized
      to Smi::uninitialized_deserialization_value at first when
      deserializing, and if base_pointer was deferred, we will
      mistakenly check JSTypedArray not on heap.
      
      Bug: v8:13149
      Change-Id: I104c83ff9a2017de1c8071a9e116baa602f6977d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3813068Reviewed-by: 's avatarJakob Linke <jgruber@chromium.org>
      Commit-Queue: 王澳 <wangao.james@bytedance.com>
      Cr-Commit-Position: refs/heads/main@{#82254}
      d69c7937
  6. 04 Aug, 2022 2 commits
  7. 03 Aug, 2022 1 commit
  8. 02 Aug, 2022 1 commit
  9. 29 Jul, 2022 2 commits
  10. 28 Jul, 2022 2 commits
    • Seth Brenith's avatar
      Reland "Background merging of deserialized scripts" · 766b2a4d
      Seth Brenith authored
      This is a reland of commit e895b7af
      
      The unit test has been updated to work correctly when
      --stress-incremental-marking is enabled.
      
      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: Id2036dfa4eba8670cac899773d7a906825fa2c50
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787266Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#82045}
      766b2a4d
    • Clemens Backes's avatar
      [wasm] Do not allocate guard regions for memory64 · 965e688d
      Clemens Backes authored
      Memory64 currently does not use trap handling, so we should not allocate
      a guard region (10GB total reservation).
      This is implemented by adding a {WasmMemoryFlag} enum in the backing
      store header, which replaces the previous {MemoryIndexType}. The flag is
      not stored with the backing store, as the backing store does not care
      about the index type, and we might want to share the same backing store
      for memory32 and memory64 (if sizes permit this).
      Instead, we (still) store the flag with the WasmMemoryObject and pass it
      to the backing store methods.
      
      R=jkummerow@chromium.org
      
      Bug: v8:10949
      Change-Id: I284b85b98d181ba5e8d454b24bfa48f6ac201be5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789506Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#82038}
      965e688d
  11. 25 Jul, 2022 2 commits
    • 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
    • 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
  12. 21 Jul, 2022 1 commit
  13. 19 Jul, 2022 1 commit
  14. 18 Jul, 2022 1 commit
  15. 15 Jul, 2022 2 commits
  16. 14 Jul, 2022 1 commit
    • Samuel Groß's avatar
      [sandbox] Fix serialization of raw external references · 63e054f5
      Samuel Groß authored
      When testing the serializer (e.g. via --stress-snapshot), raw external
      references (i.e. just raw pointers) can be embedded inside the snapshot.
      When those pointers are sandboxed, the corresponding external pointer
      tag also needs to be encoded in the snapshot. This CL adds the necessary
      logic to support this by introducing new serializer Bytecodes for raw
      external references and encoding the raw pointers together with the tag.
      
      Bug: v8:10391
      Change-Id: I7b3710c2144e19f7507e3f6db537d250d102ee28
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762575Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81723}
      63e054f5
  17. 13 Jul, 2022 1 commit
  18. 11 Jul, 2022 2 commits
    • Samuel Groß's avatar
      [sandbox] Fix --stress-snapshot after recent sandbox changes · 7683b9cd
      Samuel Groß authored
      There seem to be some issues with sandboxed external references in the
      serializer which cause the --stress-snapshot mode to fail. This CL
      changes the serializer to serialize external pointers that are
      unsandboxed (currently all of them) as "regular" external references,
      not "sandboxed" ones. This should fix the issues on the bots.
      
      Bug: v8:10391
      Change-Id: I2f889e1d0aa9c5958d4f4337e114423b650c1bb2
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3755148Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81643}
      7683b9cd
    • Samuel Groß's avatar
      [sandbox] Prepare ExternalPointerTable rollout · 8a59678b
      Samuel Groß authored
      This CL does the following:
      - It enables (i.e. allocates and initializes) the per-Isolate
        ExternalPointerTable when the sandbox is enabled.
      - It refactors the list of external pointer tags to mark them as
        "sandboxed" or "unsandboxed". An unsandboxed external pointer has a
        null tag.
      - It changes V8_SANDBOXED_EXTERNAL_POINTERS to now essentially just
        enable sandboxing for all available tags.
      - It modifies all low-level external pointer accessors to perform the
        ExternalPointerLookup only if the tag is non-zero and otherwise treat
        the slot as containing a raw pointer.
      
      This now allows rolling out external pointer sandboxing incrementally
      (separately for each external pointer type), which will in turn allow
      for more precise performance measurements of the impact of the sandbox.
      
      Note: when an external pointer tag is now marked as sandboxed (and
      V8_SANDBOXED_EXTERNAL_POINTERS is not enabled), the underlying slots are
      still 64-bits in size. This simplifies the implementation as we would
      otherwise need to deal with variably-sized external pointer slots. Local
      benchmarking suggests that the benefits from 32-bit external pointer
      slots are insignificant on typical benchmarks, so this should be ok.
      
      Drive-by: rename kExternalPointerSize to kExternalPointerSlotSize to
      make it more clear what it refers to (the on-heap storage size). Also
      delete CodeStubAssembler::InitializeExternalPointerField as it is not
      currently used and the implementation is fairly inefficient.
      
      Bug: v8:10391
      Change-Id: I7c38729c7e9048d737a1a8ced84749f5b1f7feab
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3736447Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81636}
      8a59678b
  19. 07 Jul, 2022 1 commit
  20. 01 Jul, 2022 1 commit
  21. 29 Jun, 2022 1 commit
  22. 27 Jun, 2022 2 commits
    • Samuel Groß's avatar
      [sandbox] Turn ExternalPointerTag into a template parameter · 8ca93205
      Samuel Groß authored
      The ExternalPointerTags are assumed to be compile-time constants in most
      cases, so turning them into template parameters enforces that. As
      decisions such as whether to use the per-isolate or the shared external
      pointer table are encoded into the tag values, forcing those to be
      compile-time constants guarantees that the compiler will be able to
      inline the correct logic when accessing an external pointer.
      
      With this, there are now two (high-level) ways of accessing external pointer fields from C++: the Read/WriteExternalPointerField methods
      which require the ExternalPointerTag to be a template parameter, and the
      ExternalPointerSlot class which takes the tag as an argument. The latter
      is for example used for snapshot deserialization and by the garbage
      collector (more generally, by the ObjectVisitor::VisitExternalPointer
      method), where the tag is not a compile-time constant.
      
      Finally, this CL also introduces a new ExternalPointerHandle type which
      represents the (opaque) on-heap representation of a reference to an
      entry in an ExternalPointerTable when sandboxing is enabled. Making this
      its own type makes the code a bit more readable.
      
      Bug: v8:10391
      Change-Id: I867b8ce41d15d485f1dc66786f233c710c56afcb
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3720641Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81402}
      8ca93205
    • Samuel Groß's avatar
      [snapshot] Simplify ArrayBuffer deserialization · 087d2255
      Samuel Groß authored
      It is no longer necessary to postpone the allocation of backing stores
      to avoid triggering GC. As such, the logic around ArrayBuffer
      deserialization can be simplified.
      
      Bug: v8:10391, v8:11111
      Change-Id: I7410392a6e658cd4be77e2192483c6d412b63412
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3717982Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81384}
      087d2255
  23. 24 Jun, 2022 2 commits
  24. 23 Jun, 2022 3 commits
  25. 22 Jun, 2022 2 commits
    • Samuel Groß's avatar
      [sandbox] Fix two deserializer issues when sandbox is enabled · 9d3a645b
      Samuel Groß authored
      When the sandbox is enabled, an empty ArrayBuffer does not have a
      nullptr backing store but instead points to a special EmptyBackingStore
      pseudo-object inside the sandbox. This then requires special handling
      during deserialization. This CL fixes two cases where this was not done
      correctly, which caused some crashes when --stress-snapshot is active.
      
      Bug: v8:10391
      Change-Id: I412adace229b979b317864a3e8c12ed4c601b850
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716480Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81297}
      9d3a645b
    • Igor Sheludko's avatar
      Revert "[arm64] Increase code alignment to 64" · b81af94a
      Igor Sheludko authored
      This reverts commit 319e747a.
      
      Reason for revert: it brought unexpected performance regressions.
      
      Original change's description:
      > [arm64] Increase code alignment to 64
      >
      > This should fix unexpected regressions which occur after builtins
      > modifications.
      >
      > This CL affects alignment of embedded builtins on all configurations
      > and Code header size only for non-pointer compression configuration.
      >
      > Bug: v8:11708
      > Change-Id: I8058197c5b768a699e7f52446424013e86203b57
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3700392
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#81113}
      
      Bug: v8:11708
      Change-Id: I238e799284d59e80dee244b240fe2a72c33e83b0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716485
      Auto-Submit: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#81292}
      b81af94a
  26. 21 Jun, 2022 1 commit