Skip to content

V
V8
Switch branch/tag
  1. 06 Oct, 2020 1 commit
    • Ulan Degenbaev's avatar
      Revert "[heap] Convert WeakObjects to heap::base::Worklist" · a282d2e9
      Ulan Degenbaev authored 
      This reverts commit 969cdfe6.

Reason for revert: speculative revert for crbug.com/1135472

Original change's description:
> [heap] Convert WeakObjects to heap::base::Worklist
>
> This splits WeakObjects into explicit global and local worklists.
> The latter are defined in WeakObjects::Local and are thread-local.
>
> The main thread local worklist is stored in
> MarkCompactCollector::local_weak_objects and exists during marking
> similar to local_marking_worklists. Concurrent markers create their
> own local worklists that are published at the end.
>
> Change-Id: I093fdc580b4609ce83455b860b90a5099085beac
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440607
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70317}

TBR=ulan@chromium.org,dinfuehr@chromium.org

Change-Id: I3fa3bfdcf3c359f46a3b56c19fb4e486883cde9d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2452749Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70344}
      a282d2e9
  3. 05 Oct, 2020 1 commit
  5. 01 Oct, 2020 1 commit
  7. 24 Sep, 2020 1 commit
  9. 11 Aug, 2020 1 commit
    • Ulan Degenbaev's avatar
      [heap] Split marking worklist into global worklist and local worklists · 28133adc
      Ulan Degenbaev authored 
      This is the first step in refactoring Worklist to allow arbitrary
number of local worklists with private segments:
- Introduce MarkingWorklistImpl<> which will eventually replace
  (and will be renamed to) Worklist.
- MarkingWorklistImpl<> owns the global pool of segments but does not
  keep track of private segments.
- MarkingWorklistImpl<>::Local owns private segments and can be
  constructed dynamically on background threads.
- Rename the existing MarkingWorklistsHolder to MarkingWorklists.
- Rename the existing MarkingWorklists to MarkingWorklists::Local.
- Rename the existing marking_workists_holder to marking_worklists.
- Rename the existing marking_worklists to local_marking_worklists.

Design doc: https://bit.ly/2XMtjLi
Bug: v8:10315

Change-Id: I9da34883ad34f4572fccd40c51e51eaf50c617bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2343330Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69330}
      28133adc
  11. 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
  13. 06 May, 2020 1 commit
  15. 26 Feb, 2020 1 commit
  17. 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
  19. 08 Nov, 2019 1 commit
  21. 05 Nov, 2019 1 commit
  23. 04 Nov, 2019 1 commit
  25. 30 Oct, 2019 1 commit
  27. 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
  29. 16 Oct, 2019 1 commit
  31. 25 Sep, 2019 1 commit
  33. 23 May, 2019 1 commit
  35. 21 May, 2019 1 commit
  37. 20 May, 2019 1 commit
  39. 02 May, 2019 1 commit
  41. 30 Apr, 2019 3 commits
  43. 29 Apr, 2019 2 commits
  45. 01 Apr, 2019 1 commit
  47. 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
  49. 18 Mar, 2019 1 commit
  51. 15 Feb, 2019 1 commit
  53. 30 Jan, 2019 1 commit
  55. 29 Jan, 2019 1 commit
  57. 22 Jan, 2019 1 commit
  59. 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
  61. 15 Jan, 2019 1 commit
  63. 14 Jan, 2019 2 commits
  65. 11 Jan, 2019 2 commits
  67. 09 Jan, 2019 1 commit