1. 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
  2. 05 Jul, 2022 1 commit
  3. 31 May, 2022 1 commit
    • Joyee Cheung's avatar
      Revert "[heap] pre-populate the single_character_string_cache" · 4bdbccc3
      Joyee Cheung authored
      This reverts commit 07e11a64.
      
      Reason for revert: caused regressions and heap verification failures
      
      Bug: chromium:1330410, chromium:1330408, chromium:1330413
      
      Original change's description:
      > [heap] pre-populate the single_character_string_cache
      >
      > This simplifies the code and removes the runtime overhead of
      > spontaneously adding strings to the cache.
      >
      > Bug: v8:12718
      > Change-Id: I2ed49bd82e3baf2563eeb8f463be72c0308c52c5
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616553
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Joyee Cheung <joyee@igalia.com>
      > Cr-Commit-Position: refs/heads/main@{#80803}
      
      Bug: v8:12718
      Change-Id: I569fea9e34effd57c9e7c65190cf5b4ec0b0623b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3679680
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Owners-Override: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80870}
      4bdbccc3
  4. 30 May, 2022 1 commit
  5. 13 May, 2022 1 commit
  6. 21 Feb, 2022 1 commit
  7. 16 Feb, 2022 1 commit
  8. 07 Feb, 2022 1 commit
    • Thibaud Michaud's avatar
      [wasm] Fix typing of stack-switching wrappers · 08b3da7f
      Thibaud Michaud authored
      - Suspender.suspendOnReturnedPromise expects a function with type
      [ti*]->[externref] and returns a function with the same type.
      - Suspender.returnPromiseOnSuspend expects a function with type
      [ti*]->[to] and returns a function with type [ti*]->[externref].
      
      Changes:
      - Check the wrapped function's return types
      - Skip type checking of return types when importing a wrapper (and
      assert that the return type is externref)
      - Add special case for WebAssembly.Function.type of a
      WasmExportedFunction: it currently returns the signature declared by
      the module. Change the return type to externref if this is a
      stack-switching export.
      
      Bug: v8:12191
      Change-Id: I6619c306e9613825ad1b021cb3400d73cd684656
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3435190Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78973}
      08b3da7f
  9. 18 Nov, 2021 1 commit
  10. 20 Oct, 2021 1 commit
  11. 19 Oct, 2021 1 commit
    • Jakob Gruber's avatar
      [regexp] Compact codegen for large character classes · 8bbb44e5
      Jakob Gruber authored
      Large character classes may easily be created when unicode
      properties (e.g.: /\p{L}/u and /\P{L}/u) are used - these are
      expanded internally into character classes that consist of hundreds
      of character ranges. Previously to this CL, we'd emit branching code
      for each of these ranges, leading to very large regexp code objects.
      
      This CL adds a new codegen mode for large character classes (where
      'large' currently means > 16 ranges). Instead of emitting branching
      code inline, the ranges are written into a ByteArray and we call into
      the C function IsCharacterInRangeArray for the actual branching logic.
      The ByteArray is smaller than emitted code and is deduplicated if the
      same character class is matched repeatedly in the same pattern.
      
      Note this mode is *not* implemented for the interpreter, since we
      currently don't have a constant pool for irregexp bytecode, and thus
      cannot reference ByteArrays.
      
      Bug: v8:11069
      Change-Id: I2d728e42d85114b796c637f791848731a104cd54
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229377Reviewed-by: 's avatarPatrick Thier <pthier@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77463}
      8bbb44e5
  12. 13 Oct, 2021 1 commit
  13. 23 Jul, 2021 1 commit
    • Vicky Kontoura's avatar
      [web snapshot] Support classes · 8439314d
      Vicky Kontoura authored
      This CL adds support for classes with methods.
      
      More specifically:
      - A new ValueSerializer is added and classes are serialized separetely
      from functions, although the common parts are handled in the same way
      and abstracted away.
      - The function prototype is serialized as an object and any missing
      information is set up again during deserialization.
      - FunctionFlagsToFunctionKinds() is updated to allow for more function
      kinds.
      - Context serialization is updated to support serializing BlockContexts
      and creating ScopeInfos of type CLASS_SCOPE.
      - Map serialization is updated to support properties with custom
      attributes.
      
      Bug: v8:11525, v8:11706
      Change-Id: I16ca7cbc17b1811721081cda05124ce36073f9be
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3006416
      Commit-Queue: Vicky Kontoura <vkont@google.com>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75893}
      8439314d
  14. 12 Jun, 2021 1 commit
  15. 10 Jun, 2021 1 commit
  16. 17 May, 2021 1 commit
  17. 10 May, 2021 1 commit
  18. 06 Apr, 2021 1 commit
    • Shu-yu Guo's avatar
      Reland^2 "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" · 627b6b2f
      Shu-yu Guo authored
      This is a reland of e28dadc2
      
      The original failure was due to a stale Win32 bot. The reland failure
      was due to idempotent task deduplication returning the exact same
      failure. See crbug/1196064
      
      Original change's description:
      > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
      >
      > Currently, IsolateRoot is both the address of the Isolate root and the
      > base address of the pointer compression reservation. This CL teases the
      > two uses apart by renaming IsolateRoot to PtrComprCageBase.
      >
      > - In addition to V8_COMPRESS_POINTERS, add a
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      >
      > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
      >   aliases to GetPtrComprCageBase.
      >
      > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      >
      > Bug: v8:11460
      > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Auto-Submit: Shu-yu Guo <syg@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73790}
      
      Bug: v8:11460
      No-Try: true
      Tbr: ishell@chromium.org
      Tbr: rmcilroy@chromium.org
      Change-Id: Id69311cf3267ebe1297fff159de0be48b15b65a3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806546Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73795}
      627b6b2f
  19. 05 Apr, 2021 4 commits
    • Shu-yu Guo's avatar
      Revert "Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase"" · 562c4251
      Shu-yu Guo authored
      This reverts commit 15c78b45.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32277/overview
      
      Original change's description:
      > Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase"
      >
      > This is a reland of e28dadc2
      >
      > Relanding to see if Win32 rel failures from
      > https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/overview
      > were infra flakes. Could not repro on try bots.
      >
      > Original change's description:
      > > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
      > >
      > > Currently, IsolateRoot is both the address of the Isolate root and the
      > > base address of the pointer compression reservation. This CL teases the
      > > two uses apart by renaming IsolateRoot to PtrComprCageBase.
      > >
      > > - In addition to V8_COMPRESS_POINTERS, add a
      > >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      > >
      > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
      > >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
      > >   aliases to GetPtrComprCageBase.
      > >
      > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      > >
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      >
      > No-Try: true
      > Bug: v8:11460
      > Tbr: ishell@chromium.org
      > Tbr: rmcilroy@chromium.org
      > Change-Id: I0a8c3a48999d6737c8c64d2c2703607f14f3fdd0
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806169
      > Reviewed-by: Shu-yu Guo <syg@chromium.org>
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73792}
      
      Bug: v8:11460
      Change-Id: Ifee92d622c43a91c15f45ef94ff739237bd2024b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806545
      Auto-Submit: Shu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73793}
      562c4251
    • Shu-yu Guo's avatar
      Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" · 15c78b45
      Shu-yu Guo authored
      This is a reland of e28dadc2
      
      Relanding to see if Win32 rel failures from
      https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/overview
      were infra flakes. Could not repro on try bots.
      
      Original change's description:
      > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
      >
      > Currently, IsolateRoot is both the address of the Isolate root and the
      > base address of the pointer compression reservation. This CL teases the
      > two uses apart by renaming IsolateRoot to PtrComprCageBase.
      >
      > - In addition to V8_COMPRESS_POINTERS, add a
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      >
      > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
      >   aliases to GetPtrComprCageBase.
      >
      > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      >
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      
      No-Try: true
      Bug: v8:11460
      Tbr: ishell@chromium.org
      Tbr: rmcilroy@chromium.org
      Change-Id: I0a8c3a48999d6737c8c64d2c2703607f14f3fdd0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806169Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73792}
      15c78b45
    • Francis McCabe's avatar
      Revert "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" · 07a9ff4d
      Francis McCabe authored
      This reverts commit e28dadc2.
      
      Reason for revert: failed test262 tests;; see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/steps?succeeded=true&debug=false
      
      Original change's description:
      > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
      >
      > Currently, IsolateRoot is both the address of the Isolate root and the
      > base address of the pointer compression reservation. This CL teases the
      > two uses apart by renaming IsolateRoot to PtrComprCageBase.
      >
      > - In addition to V8_COMPRESS_POINTERS, add a
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      >
      > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
      >   aliases to GetPtrComprCageBase.
      >
      > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      >
      > Bug: v8:11460
      > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Auto-Submit: Shu-yu Guo <syg@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73790}
      
      Bug: v8:11460
      Change-Id: I19d0e28194fcdb28e89f129a7694ca3fe29fa17a
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806168
      Auto-Submit: Francis McCabe <fgm@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@{#73791}
      07a9ff4d
    • Shu-yu Guo's avatar
      [ptr-cage] Rename IsolateRoot to PtrComprCageBase · e28dadc2
      Shu-yu Guo authored
      Currently, IsolateRoot is both the address of the Isolate root and the
      base address of the pointer compression reservation. This CL teases the
      two uses apart by renaming IsolateRoot to PtrComprCageBase.
      
      - In addition to V8_COMPRESS_POINTERS, add a
        V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      
      - Rename GetIsolate* helpers to GetPtrComprCageBase. When
        V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
        aliases to GetPtrComprCageBase.
      
      - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      
      Bug: v8:11460
      Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Auto-Submit: Shu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73790}
      e28dadc2
  20. 24 Feb, 2021 1 commit
  21. 20 Nov, 2020 1 commit
  22. 10 Nov, 2020 1 commit
  23. 09 Nov, 2020 2 commits
  24. 07 Nov, 2020 1 commit
  25. 28 Oct, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] generate C++ class definitions per Torque file · 03f60296
      Tobias Tebbi authored
      This CL splits the class definitions per .tq file, to realize the
      following relationship:
      A class defined in src/objects/foo.tq has a C++ definition in
      src/objects/foo.h. Torque then generates:
      
      - torque-generated/src/objects/foo-tq.inc
        An include file (no proper header) to be included in src/objects/foo.h
        containing the Torque-generated C++ class definition.
      
      - torque-generated/src/objects/foo-tq-inl.inc
        An include file (no proper header) to be included in
        src/objects/foo-inl.h containing inline function definitions.
      
      - torque-generated/src/objects/foo-tq.cc
        A source file including src/objects/foo-inl.h that contains non-inline
        function definitions.
      
      Advantages of this approach:
      - Avoid big monolithic headers and preserve the work that went into
        splitting objects.h
      - Moving a definition to Torque keeps everything in the same place
        from a C++ viewpoint, including a fully Torque-generated C++ class
        definition.
      - The Torque-generated include files do not need to be independent
        headers, necessary includes or forward declarations can just be added
        to the headers that include them.
      
      Drive-by changes:
      A bunch of definitions and files had to be moved or created to realize
      a consistent 1:1 relationship between .tq files and C++ headers.
      
      
      Bug: v8:7793
      TBR: hpayer@chromium.org
      Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70853}
      03f60296
  26. 07 Oct, 2020 1 commit
  27. 25 Sep, 2020 1 commit
    • Tobias Tebbi's avatar
      Reland "[torque] refactor: use -tq only in filenames derived from .tq files" · 21b58516
      Tobias Tebbi authored
      This is a reland of 64caf2b0
      
      Original change's description:
      > [torque] refactor: use -tq only in filenames derived from .tq files
      >
      > This is to establish a naming rule for Torque-generated files:
      > - If the file is called foo/bar-tq..., then it is derived from a
      >   file foo/bar.tq
      > - Otherwise it doesn't belong to a specific .tq file.
      >
      > So far, we attached -tq to all Torque-generated file names, where it
      > sometimes corresponded to a .tq file name and sometimes not.
      > It is not necessary to add -tq to file names to indicate that they are
      > Torque-generated, since they are already in a directory called
      > torque-generated, and we always refer to them as
      > "torque-generated/filename", so there is no confusion even though some
      > files now have the same name as a corresponding hand-written file, for
      > example factory.cc.
      >
      > TBR: hpayer@chromium.org
      > Bug: v8:7793
      > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70060}
      
      Bug: v8:7793
      TBR: hpayer@chromium.org jgruber@chromium.org
      Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70137}
      21b58516
  28. 22 Sep, 2020 2 commits
    • Francis McCabe's avatar
      Revert "[torque] refactor: use -tq only in filenames derived from .tq files" · 92aaace1
      Francis McCabe authored
      This reverts commit 64caf2b0.
      
      Reason for revert: Seems to be causing a failure:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809?
      
      Original change's description:
      > [torque] refactor: use -tq only in filenames derived from .tq files
      > 
      > This is to establish a naming rule for Torque-generated files:
      > - If the file is called foo/bar-tq..., then it is derived from a
      >   file foo/bar.tq
      > - Otherwise it doesn't belong to a specific .tq file.
      > 
      > So far, we attached -tq to all Torque-generated file names, where it
      > sometimes corresponded to a .tq file name and sometimes not.
      > It is not necessary to add -tq to file names to indicate that they are
      > Torque-generated, since they are already in a directory called
      > torque-generated, and we always refer to them as
      > "torque-generated/filename", so there is no confusion even though some
      > files now have the same name as a corresponding hand-written file, for
      > example factory.cc.
      > 
      > TBR: hpayer@chromium.org
      > Bug: v8:7793
      > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70060}
      
      TBR=jgruber@chromium.org,tebbi@chromium.org
      
      Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70065}
      92aaace1
    • Tobias Tebbi's avatar
      [torque] refactor: use -tq only in filenames derived from .tq files · 64caf2b0
      Tobias Tebbi authored
      This is to establish a naming rule for Torque-generated files:
      - If the file is called foo/bar-tq..., then it is derived from a
        file foo/bar.tq
      - Otherwise it doesn't belong to a specific .tq file.
      
      So far, we attached -tq to all Torque-generated file names, where it
      sometimes corresponded to a .tq file name and sometimes not.
      It is not necessary to add -tq to file names to indicate that they are
      Torque-generated, since they are already in a directory called
      torque-generated, and we always refer to them as
      "torque-generated/filename", so there is no confusion even though some
      files now have the same name as a corresponding hand-written file, for
      example factory.cc.
      
      TBR: hpayer@chromium.org
      Bug: v8:7793
      Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70060}
      64caf2b0
  29. 10 Sep, 2020 1 commit
    • Sathya Gunasekaran's avatar
      [turboprop] Unroll loop in the dynamic map checks operator · 9c67790b
      Sathya Gunasekaran authored
      The dynamic map checks operator loads the feedback vector and performs
      map checks against each map and handler entry in the feedback against
      the incoming map and handler.
      
      Instead of emitting code to iterate over this feedback vector at
      runtime, we unroll this loop at compile time.
      
      The generated code is similar to this pseudocode:
      
        length = feedback_slot.length
        if length >= 4: goto labels[3]
        if length == 3: goto labels[2]
        if length == 2: goto labels[1]
        if length == 1: goto labels[0]
      
        labels[3]:
          map = load(feedback_slot, 6)
          if incoming_map == map goto handler_check(7)
          goto labels[2]
        labels[2]:
          map = load(feedback_slot, 4)
          if incoming_map == map goto handler_check(5)
          goto labels[1]
        labels[1]:
          map = load(feedback_slot, 2)
          if incoming_map == map goto handler_check(3)
          goto labels[0]
        labels[0]:
          map = load(feedback_slot, 0)
          if incoming_map == map goto handler_check(1)
          bailout
      
        handler_check (index):
          handler = load(feedback_slot, index)
          if incoming_handler ==  handler goto done
          deoptimize
      
      Bug: v8:10582, v8:9684
      Change-Id: I64d64ff8eda664e4d476bf1b2612e26a344e98a6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339960
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69797}
      9c67790b
  30. 06 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [runtime] Move string table off-heap · 1546be9c
      Leszek Swirski authored
      Changes the isolate's string table into an off-heap structure. This
      allows the string table to be resized without allocating on the V8 heap,
      and potentially triggering a GC. This allows existing strings to be
      inserted into the string table without requiring allocation.
      
      This has two important benefits:
      
        1) It allows the deserializer to insert strings directly into the
           string table, rather than having to defer string insertion until
           deserialization completes.
      
        2) It simplifies the concurrent string table lookup to allow resizing
           the table inside the write lock, therefore eliminating the race
           where two concurrent lookups could both resize the table.
      
      The off-heap string table has the following properties:
      
        1) The general hashmap behaviour matches the HashTable, i.e. open
           addressing, power-of-two sized, quadratic probing. This could, of
           course, now be changed.
      
        2) The empty and deleted sentinels are changed to Smi 0 and 1,
           respectively, to make those comparisons a bit cheaper and not
           require roots access.
      
        3) When the HashTable is resized, the old elements array is kept
           alive in a linked list of previous arrays, so that concurrent
           lookups don't lose the data they're accessing. This linked list
           is cleared by the GC, as then we know that all threads are in
           a safepoint.
      
        4) The GC treats the hash table entries as weak roots, and only walks
           them for non-live reference clearing and for evacuation.
      
        5) Since there is no longer a FixedArray to serialize for the startup
           snapshot, there is now a custom serialization of the string table,
           and the string table root is considered unserializable during weak
           root iteration. As a bonus, the custom serialization is more
           efficient, as it skips non-string entries.
      
      As a drive-by, rename LookupStringExists_NoAllocate to
      TryStringToIndexOrLookupExisting, to make it clearer that it returns
      a non-string for the case when the string is an array index. As another
      drive-by, extract StringSet into a separate header.
      
      Bug: v8:10729
      Change-Id: I9c990fb2d74d1fe222920408670974a70e969bca
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339104
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69270}
      1546be9c
  31. 22 Jul, 2020 1 commit
  32. 09 Jul, 2020 1 commit
  33. 10 Jun, 2020 1 commit
  34. 11 May, 2020 1 commit
    • Seth Brenith's avatar
      [torque][cleanup] Simplify some Torque-defined classes · e7693985
      Seth Brenith authored
      This CL is pretty mechanical; I just iterated through some Torque
      classes making the following changes:
      
      - Use @generateCppClass if it seems easy to
      - Use @generatePrint if the existing printer doesn't do anything special
      - Fix up any imprecise field types
      
      It also includes two minor changes to implementation-visitor:
      
      - Add a new -inl.h file with the things needed for
        torque-generated/class-definitions-tq.cc so we don't need to keep
        changing the compiler when we add @generateCppClass.
      - Avoid emitting incorrect accessors for ExternalPointers. This isn't
        strictly necessary for correctness, as the accessors defined in C++
        already hide the ones inherited from generated code, but it makes me
        feel safer.
      
      Change-Id: I4d5a8ba6f86ebff57a0d147619212a3993b087c0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2185824Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#67719}
      e7693985