1. 17 Jun, 2020 1 commit
    • Dan Elphick's avatar
      [heap] Use BasicMemoryChunk::FromHeapObject more · 6f267e8a
      Dan Elphick authored
      Since ReadOnlySpace pages will soon not be MemoryChunks, change most
      uses of MemoryChunk::FromHeapObject and FromAddress to use the
      BasicMemoryChunk variants and which use the new MemoryChunk::cast
      function that takes a BasicMemoryChunk and DCHECKs !InReadOnlySpace().
      
      To enable this, it also moves into BasicMemoryChunk several MemoryChunk
      functions that just require a BasicMemoryChunk.
      
      Bug: v8:10454
      Change-Id: I80875b2c2446937ac2c2bc9287d36e71cc050c38
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2243216
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68390}
      6f267e8a
  2. 06 May, 2020 1 commit
  3. 26 Feb, 2020 1 commit
  4. 11 Dec, 2019 1 commit
    • Ulan Degenbaev's avatar
      [heap] Refactor marking worklists · 6b5bc5e9
      Ulan Degenbaev authored
      This unifies marking worklists handling by the main thread marker and
      by the concurrent markers. A new class called MarkingWorklistsHolder
      owns all marking worklists: the default worklist, the on-hold worklist,
      and the embedder worklist. Each thread creates a local view of the
      marking worklists by creating an instance of MarkingWorklists.
      
      Additionally, marking visitors now work on MarkingWorklists instead of
      accessing each worklist individually.
      
      Besides cleaning the code up, this CL provides a bottleneck for
      implementing per-context worklists.
      
      Bug: chromium:973627
      Change-Id: I52ad65c94bc0695287ba7bf4d8a814a9035e2888
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1941947Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65421}
      6b5bc5e9
  5. 08 Nov, 2019 1 commit
  6. 05 Nov, 2019 1 commit
  7. 04 Nov, 2019 1 commit
  8. 30 Oct, 2019 1 commit
  9. 28 Oct, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Use generated instance types, part 1 · 91e6421c
      Seth Brenith authored
      This change begins making use of the fact that Torque now knows about
      the relationship between classes and instance types, to replace a few
      repetitive lists:
      
      - Instance type checkers (single and range), defined in
        src/objects/instance-type.h
      - Verification dispatch in src/diagnostics/objects-debug.cc
      - Printer dispatch in src/diagnostics/objects-printer.cc
      - Postmortem object type detection in
        tools/debug_helper/get-object-properties.cc
      
      Torque is updated to generate four macro lists for the instance types,
      representing all of the classes separated in two dimensions: classes
      that correspond to a single instance type versus those that have a
      range, and classes that are fully defined in Torque (with fields and
      methods inside '{}') versus those that are only declared. The latter
      distinction is useful because fully-defined classes are guaranteed to
      correspond to real C++ classes, whereas only-declared classes are not.
      
      A few other changes were required to make the lists above work:
      
      - Renamed IsFiller to IsFreeSpaceOrFiller to better reflect what it does
        and avoid conflicts with the new macro-generated IsFiller method. This
        is the part I'm most worried about: I think the new name is an
        improvement for clarity and consistency, but I could imagine someone
        typing IsFiller out of habit and introducing a bug. If we'd prefer to
        keep the name IsFiller, my other idea is to rename FreeSpace to
        VariableSizeFiller and Filler to FixedSizeFiller.
      - Made Tuple3 extend from Struct, not Tuple2, because IsTuple2 is
        expected to check for only TUPLE2_TYPE and not include TUPLE3_TYPE.
      - Normalized the dispatched behavior for BigIntBase and HeapNumber.
      - Added a few new object printers.
      
      Bug: v8:7793
      Change-Id: I5462bb105f8a314baa59bd6ab6ab6215df6f313c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860314
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64597}
      91e6421c
  10. 16 Oct, 2019 1 commit
  11. 25 Sep, 2019 1 commit
  12. 23 May, 2019 1 commit
  13. 21 May, 2019 1 commit
  14. 20 May, 2019 1 commit
  15. 02 May, 2019 1 commit
  16. 30 Apr, 2019 3 commits
  17. 29 Apr, 2019 2 commits
  18. 01 Apr, 2019 1 commit
  19. 21 Mar, 2019 1 commit
    • Michael Lippautz's avatar
      heap: Fix incremental-concurrent processing of large FixedArray · c4eae87a
      Michael Lippautz authored
      FixedArray object in LO space are processed incrementally in ranges of slots
      size kProgressBarScanningChunk to reduce latency when returning to the
      processing loop is critical. A progress bar stores how much slots have been
      processed already.
      
      In the case of regular concurrent marking there was a guarantee that the
      object was only processed by one thread (main *or* concurrent marking
      thread) at the same time.
      
      However, some optimizations that avoid write barriers for each
      individual write operation emit a batched write barrier that requires
      re-visiting the FixedArray for the marking barrier. In such cases, the
      progress bar would be reset using relaxed stores which is problematic as
      the concurrent marking thread could race on setting its own progress on the
      progress bar. As a result, the array would only be re-scanned partially.
      
      The fix involves using CAS to set the progress bar and bail out in the
      case an inconsistent state was observed.
      
      In the following:
      MT... main thread
      CM... concurrent marking thread
      
      The interesting cases are:
      1. MT *or* CM processes the array without interfering: Progress bar is
         updated monotonically without failing.
      3. MT interferes with itself: The progress bar is just reset and the main
         thread will restart scanning from index 0. The object is added twice to
         the marking worklist and processed each time one of the entries is
         retrieved from the worklist.
      4. MT interferes with CM:
         4.a.: CM processes a range of slots and re-adds the left overs by
         setting the progress bar and re-adding the array to the worklist.  In
         this case CM *and* MT process the array from index 0. The first time
         the CAS for setting the progress bar fails on either of the threads,
         the looser will bail out and leave processing for the winner.
         4.b.: CM is interrupted while processing a range of the array and
         fails in setting the progress bar for the left overs. In this case
         the CM bails out right away and the main thread starts processing
         from index 0.
      
      In addition, there is a transition from index 0 to the index of the
      first actual slot. This transition makes it possible to observe a reset
      while processing the first actual chunk of slots.
      
      Bug: chromium:942699
      Change-Id: I0b06f47ee075030dadfc959528cd77b6b69bbec2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532325Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60385}
      c4eae87a
  20. 18 Mar, 2019 1 commit
  21. 15 Feb, 2019 1 commit
  22. 30 Jan, 2019 1 commit
  23. 29 Jan, 2019 1 commit
  24. 22 Jan, 2019 1 commit
  25. 18 Jan, 2019 2 commits
    • Clemens Hammacher's avatar
      Revert "Reland "[GC] Ensure JSFunctions with flushed bytecode are flushed during GC."" · 1a95d4de
      Clemens Hammacher authored
      This reverts commit d5e63b03.
      
      Reason for revert: Fails gc-stress: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Mac64%20GC%20Stress/5312
      
      Original change's description:
      > Reland "[GC] Ensure JSFunctions with flushed bytecode are flushed during GC."
      > 
      > This is a reland of f5729f1c
      > 
      > TBR=ulan@chromium.org
      > 
      > Original change's description:
      > > [GC] Ensure JSFunctions with flushed bytecode are flushed during GC.
      > >
      > > When bytecode is flushed from a SFI, the JSFunctions still retain their
      > > FeedbackVector's and point to the interpreter entry trampoline. They are
      > > reset if re-executed, however if not they could hold onto the feedback
      > > vector indefinetly. This CL adds a pass the GC to detect JSFunctions that
      > > need to be reset, and performs the reset at the end of GC.
      > >
      > > BUG=v8:8395
      > >
      > > Change-Id: I3de8655aff9ff80f912b4fd51dee43eb98cfd519
      > > Reviewed-on: https://chromium-review.googlesource.com/c/1393292
      > > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#58775}
      > 
      > Bug: v8:8395
      > Change-Id: I9bc84b62332575a080561c51f08b699b91e41e4a
      > Reviewed-on: https://chromium-review.googlesource.com/c/1414859
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58924}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org
      
      Change-Id: I5d3012d4c7277ae792b0488780ff426d51dd602f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8395
      Reviewed-on: https://chromium-review.googlesource.com/c/1421838Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58925}
      1a95d4de
    • Ross McIlroy's avatar
      Reland "[GC] Ensure JSFunctions with flushed bytecode are flushed during GC." · d5e63b03
      Ross McIlroy authored
      This is a reland of f5729f1c
      
      TBR=ulan@chromium.org
      
      Original change's description:
      > [GC] Ensure JSFunctions with flushed bytecode are flushed during GC.
      >
      > When bytecode is flushed from a SFI, the JSFunctions still retain their
      > FeedbackVector's and point to the interpreter entry trampoline. They are
      > reset if re-executed, however if not they could hold onto the feedback
      > vector indefinetly. This CL adds a pass the GC to detect JSFunctions that
      > need to be reset, and performs the reset at the end of GC.
      >
      > BUG=v8:8395
      >
      > Change-Id: I3de8655aff9ff80f912b4fd51dee43eb98cfd519
      > Reviewed-on: https://chromium-review.googlesource.com/c/1393292
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58775}
      
      Bug: v8:8395
      Change-Id: I9bc84b62332575a080561c51f08b699b91e41e4a
      Reviewed-on: https://chromium-review.googlesource.com/c/1414859
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58924}
      d5e63b03
  26. 15 Jan, 2019 1 commit
  27. 14 Jan, 2019 2 commits
  28. 11 Jan, 2019 2 commits
  29. 09 Jan, 2019 1 commit
  30. 28 Dec, 2018 1 commit
    • Ulan Degenbaev's avatar
      [heap] Support fixed arrays with progress bar in the concurrent marker · 7ca8acd0
      Ulan Degenbaev authored
      Currently the concurrent marker visits any fixed array in one go
      ignoring the progress bar and does not expect seeing black arrays
      in the worklist. For this reason, if the main thread marker starts
      visiting a large array with the progress bar, then it has to re-push
      the array in the bailout worklist. So all subsequent visitations of
      the array happen on the main thread.
      
      This patch makes the progress bar thread-safe and allows the
      concurrent marker to visit arrays in chunks.
      
      Change-Id: I5e8867077ed2908b7f9c5d8bde34d0401f7fe446
      Reviewed-on: https://chromium-review.googlesource.com/c/1385164
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58484}
      7ca8acd0
  31. 26 Dec, 2018 1 commit
  32. 24 Dec, 2018 1 commit
  33. 21 Dec, 2018 2 commits
    • Sigurd Schneider's avatar
      Reland "[deoptimizer] Refactor GenerateDeoptimizationEntries" · 2a72b8ac
      Sigurd Schneider authored
      This is a reland of f63a657e
      
      Original change's description:
      > [deoptimizer] Refactor GenerateDeoptimizationEntries
      >
      > This reduces preprocessor-expanded source size by 64,359 from
      >
      > gen         (   21 files):    71,570 to    1,613,100 (   23x)
      > src         (  624 files):   367,830 to   52,964,659 (  144x)
      > test        (  392 files):   490,924 to   37,360,916 (   76x)
      > third_party (  432 files):   239,085 to    9,547,902 (   40x)
      > total       ( 1521 files): 1,184,093 to  102,461,098 (   87x)
      >
      > to
      >
      > gen         (   21 files):    71,570 to    1,613,100 (   23x)
      > src         (  624 files):   367,837 to   52,919,005 (  144x)
      > test        (  392 files):   490,924 to   37,342,211 (   76x)
      > third_party (  432 files):   239,085 to    9,547,902 (   40x)
      > total       ( 1521 files): 1,184,100 to  102,396,739 (   86x)
      >
      > Bug: v8:8562
      > Change-Id: Iee474e22ababa1e080b8d6359af4d0076903e59a
      > Reviewed-on: https://chromium-review.googlesource.com/c/1384091
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58424}
      
      TBR=jarin@chromium.org,ulan@chromium.org
      
      Bug: v8:8562
      Change-Id: I7a8a350414941f49c6155ff43e36e0cb0b2006e5
      Reviewed-on: https://chromium-review.googlesource.com/c/1387497Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58437}
      2a72b8ac
    • Sigurd Schneider's avatar
      Revert "[deoptimizer] Refactor GenerateDeoptimizationEntries" · 4b4175d7
      Sigurd Schneider authored
      This reverts commit f63a657e.
      
      Reason for revert: breaks compile on lite mode:
      
      https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8926535782549686576/+/steps/build/0/steps/compile/0/stdout
      
      
      Original change's description:
      > [deoptimizer] Refactor GenerateDeoptimizationEntries
      > 
      > This reduces preprocessor-expanded source size by 64,359 from
      > 
      > gen         (   21 files):    71,570 to    1,613,100 (   23x)
      > src         (  624 files):   367,830 to   52,964,659 (  144x)
      > test        (  392 files):   490,924 to   37,360,916 (   76x)
      > third_party (  432 files):   239,085 to    9,547,902 (   40x)
      > total       ( 1521 files): 1,184,093 to  102,461,098 (   87x)
      > 
      > to
      > 
      > gen         (   21 files):    71,570 to    1,613,100 (   23x)
      > src         (  624 files):   367,837 to   52,919,005 (  144x)
      > test        (  392 files):   490,924 to   37,342,211 (   76x)
      > third_party (  432 files):   239,085 to    9,547,902 (   40x)
      > total       ( 1521 files): 1,184,100 to  102,396,739 (   86x)
      > 
      > Bug: v8:8562
      > Change-Id: Iee474e22ababa1e080b8d6359af4d0076903e59a
      > Reviewed-on: https://chromium-review.googlesource.com/c/1384091
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58424}
      
      TBR=ulan@chromium.org,jarin@chromium.org,sigurds@chromium.org
      
      Change-Id: I06e6f95255a3cea6a428713e9e841781425dffe8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8562
      Reviewed-on: https://chromium-review.googlesource.com/c/1387494Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58425}
      4b4175d7