1. 02 May, 2019 1 commit
  2. 29 Apr, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Use Vector::begin instead of Vector::start · 4b0f9c85
      Clemens Hammacher authored
      Our {Vector} template provides both {start} and {begin} methods. They
      return exactly the same value. Since the {begin} method is needed for
      iteration, and is also what standard containers provide, this CL
      switches all uses of the {start} method to use {begin} instead.
      
      Patchset 1 was auto-generated by using this clang AST matcher:
          callExpr(
              callee(
                cxxMethodDecl(
                  hasName("start"),
                  ofClass(hasName("v8::internal::Vector")))
              ),
              argumentCountIs(0))
      
      Patchset 2 was created by running clang-format. Patchset 3 then
      removes the now unused {Vector::start} method.
      
      R=jkummerow@chromium.org
      TBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org
      
      Bug: v8:9183
      Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61081}
      4b0f9c85
  3. 26 Apr, 2019 2 commits
    • Santiago Aboy Solanes's avatar
      [ptr-compr][Turbofan] Adding missing representation changes corner cases · 6ccec5ce
      Santiago Aboy Solanes authored
      TaggedSigned to CompressedPointer, and TaggedPointer to CompressedSigned.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
      Bug: v8:7703
      Change-Id: I9a257e583527256230576c7bc3d4c4b308570d2f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585729
      Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61046}
      6ccec5ce
    • Ross McIlroy's avatar
      Revert "[csa] verify skipped write-barriers in MemoryOptimizer" · dd6c9536
      Ross McIlroy authored
      This reverts commit da7322c0.
      
      Reason for revert: Breaking the pointer compression bots, e.g.:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20pointer%20compression/3047
      
      Original change's description:
      > [csa] verify skipped write-barriers in MemoryOptimizer
      > 
      > With very few exceptions, this verifies all skipped write-barriers in
      > CSA and Torque, showing that the MemoryOptimizer together with some
      > type information on the stored value are enough to avoid unsafe skipped
      > write-barriers.
      > 
      > Changes to CSA:
      > SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
      > MemoryOptimizer by default.
      > Type information about the stored values (TNode<Smi>) is exploited to
      > safely skip write barriers for stored Smi values.
      > In some cases, the code is re-structured to make it easier to consume
      > for the MemoryOptimizer (manual branch and load elimination).
      > 
      > Changes to the MemoryOptimizer:
      > Improve the MemoryOptimizer to remove write barriers:
      > - When the store happens to a CSA-generated InnerAllocate, by ignoring
      >   Bitcasts and additions.
      > - When the stored value is the HeapConstant of an immortal immovable root.
      > - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
      > - Fast C-calls are treated as non-allocating.
      > - Runtime calls can be white-listed as non-allocating.
      > 
      > Remaining missing cases:
      > - C++-style iterator loops with inner pointers.
      > - Inner allocates that are reloaded from a field where they were just stored
      >   (for example an elements backing store). Load elimination would fix that.
      > - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
      >   We could handle that in Torque.
      > - Double-aligned allocations, which are not lowered in the MemoryOptimizer
      >   but in CSA.
      > 
      > Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
      > can be handled by overload resolution (in Torque and C++).
      > 
      > R=​jarin@chromium.org
      > TBR=mvstanton@chromium.org
      > 
      > Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61016}
      
      TBR=mvstanton@chromium.org,jarin@chromium.org,tebbi@chromium.org
      
      Change-Id: I36877cd6d08761726ef8dce8a3e3f2ce3eebe6cf
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585732Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61038}
      dd6c9536
  4. 25 Apr, 2019 1 commit
    • Tobias Tebbi's avatar
      [csa] verify skipped write-barriers in MemoryOptimizer · da7322c0
      Tobias Tebbi authored
      With very few exceptions, this verifies all skipped write-barriers in
      CSA and Torque, showing that the MemoryOptimizer together with some
      type information on the stored value are enough to avoid unsafe skipped
      write-barriers.
      
      Changes to CSA:
      SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
      MemoryOptimizer by default.
      Type information about the stored values (TNode<Smi>) is exploited to
      safely skip write barriers for stored Smi values.
      In some cases, the code is re-structured to make it easier to consume
      for the MemoryOptimizer (manual branch and load elimination).
      
      Changes to the MemoryOptimizer:
      Improve the MemoryOptimizer to remove write barriers:
      - When the store happens to a CSA-generated InnerAllocate, by ignoring
        Bitcasts and additions.
      - When the stored value is the HeapConstant of an immortal immovable root.
      - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
      - Fast C-calls are treated as non-allocating.
      - Runtime calls can be white-listed as non-allocating.
      
      Remaining missing cases:
      - C++-style iterator loops with inner pointers.
      - Inner allocates that are reloaded from a field where they were just stored
        (for example an elements backing store). Load elimination would fix that.
      - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
        We could handle that in Torque.
      - Double-aligned allocations, which are not lowered in the MemoryOptimizer
        but in CSA.
      
      Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
      can be handled by overload resolution (in Torque and C++).
      
      R=jarin@chromium.org
      TBR=mvstanton@chromium.org
      
      Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61016}
      da7322c0
  5. 10 Apr, 2019 1 commit
  6. 09 Apr, 2019 1 commit
  7. 03 Apr, 2019 1 commit
  8. 02 Apr, 2019 1 commit
  9. 26 Mar, 2019 1 commit
  10. 21 Mar, 2019 1 commit
  11. 13 Mar, 2019 1 commit
    • Clemens Hammacher's avatar
      [wasm] Keep NativeModule alive in BackgroundCompileScope · 3df442d7
      Clemens Hammacher authored
      We need to ensure that the NativeModule stays alive while any
      {BackgroundCompileScope} exists, because during that time we hold
      shared ownership of the mutex in the {BackgroundCompileToken}. If the
      {NativeModule} dies during that period, we would need to get exclusive
      ownership of the mutex and deadlock.
      
      This change requires holding a {std::weak_ptr<NativeModule>} in the
      BackgroundCompileToken instead of a raw pointer, hence it can only be
      initialized after the NativeModule was created. This is done via a
      separate {InitCompilationState} method.
      
      R=ahaas@chromium.org
      
      Bug: v8:8979
      Change-Id: Ia14bd272ea0bc47aec547024da6020608418c9d2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1518178
      Auto-Submit: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60203}
      3df442d7
  12. 06 Mar, 2019 1 commit
  13. 05 Mar, 2019 1 commit
  14. 15 Feb, 2019 1 commit
  15. 14 Feb, 2019 1 commit
  16. 12 Feb, 2019 2 commits
  17. 11 Feb, 2019 1 commit
  18. 02 Feb, 2019 1 commit
  19. 01 Feb, 2019 3 commits
  20. 31 Jan, 2019 1 commit
  21. 30 Jan, 2019 2 commits
  22. 29 Jan, 2019 3 commits
  23. 28 Jan, 2019 2 commits
  24. 25 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      [wasm] Move Isolate management to WasmEngine · a1ff298d
      Clemens Hammacher authored
      The WasmCodeManager held a list of all Isolates that use the
      WasmEngine/WasmCodeManager (those two are 1:1).
      Since we want to move all isolate-specific tasks (like code logging and
      compilation callbacks) to the WasmEngine, this CL moves this management
      from the WasmCodeManager to the WasmEngine. We now have a bidirectional
      mapping from NativeModules to the Isolates that use them, and from an
      Isolate to all the NativeModules it uses (n:n).
      The IsolateData struct will be extended in follow-up CLs to hold things
      like the ForegroundTaskRunner. The Isolate* in the NativeModule /
      CompilationState will eventually be removed.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8689
      Change-Id: Ic2c003c3949f73ce3264dd9dac96884a5c0b9896
      Reviewed-on: https://chromium-review.googlesource.com/c/1433793
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59092}
      a1ff298d
  25. 18 Jan, 2019 1 commit
  26. 11 Jan, 2019 1 commit
  27. 10 Jan, 2019 1 commit
  28. 08 Jan, 2019 1 commit
  29. 02 Jan, 2019 1 commit
  30. 26 Dec, 2018 1 commit
  31. 20 Dec, 2018 1 commit
  32. 19 Dec, 2018 1 commit