Skip to content

V
V8
Switch branch/tag
  1. 26 Jan, 2021 1 commit
  3. 13 Jan, 2021 1 commit
  5. 12 Jan, 2021 1 commit
  7. 15 Dec, 2020 1 commit
  9. 26 Nov, 2020 1 commit
  11. 23 Oct, 2020 1 commit
  13. 16 Oct, 2020 1 commit
  15. 06 Oct, 2020 2 commits
    • 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
    • Ulan Degenbaev's avatar
      Split v8_enable_concurrent_marking into two flags · acf5e1aa
      Ulan Degenbaev authored 
      The new flags are
- v8_enable_atomic_object_field_writes that makes field write operations
  relaxed atomic.
- v8_enable_atomic_marking_state that makes the marking state and the
  write-barrier thread-safe.

The motivation is that we want to disable atomic object fields while
keeping the marking states thread-safe. This allows us to increase
TSAN coverage for background compilation and streaming tasks while
keeping the write-barrier used by the tasks thread-safe.

Bug: v8:10988
Change-Id: I11d66954dda4bf36d24c5e6f14ee5bc7a0f86094
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448467Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70329}
      acf5e1aa
  17. 05 Oct, 2020 1 commit
  19. 01 Oct, 2020 3 commits
  21. 24 Sep, 2020 1 commit
  23. 22 Sep, 2020 1 commit
  25. 21 Sep, 2020 1 commit
  27. 12 Aug, 2020 1 commit
  29. 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
  31. 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
  33. 14 Jul, 2020 1 commit
  35. 13 Jul, 2020 1 commit
  37. 10 Jul, 2020 1 commit
  39. 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
  41. 05 Jun, 2020 1 commit
    • Dan Elphick's avatar
      Revert "[heap] Make ReadOnlySpace use bump pointer allocation" · f78d69fa
      Dan Elphick authored 
      This reverts commit 81c34968 and also
490f3580 which depends on the former.

Reason for revert: Break CFI tests in chromium https://ci.chromium.org/p/chromium/builders/ci/Linux%20CFI/17438
Original change's description:
> [heap] Make ReadOnlySpace use bump pointer allocation
>
> This changes ReadOnlySpace to no longer be a PagedSpace but instead it
> is now a BaseSpace. BasicSpace is a new base class that Space inherits
> from and which has no allocation methods and does not dictate how the
> pages should be held.
>
> ReadOnlySpace unlike Space holds its pages as a
> std::vector<ReadOnlyPage>, where ReadOnlyPage directly subclasses
> BasicMemoryChunk, meaning they do not have prev_ and next_ pointers and
> cannot be held in a heap::List. This is desirable since with pointer
> compression we would like to remap these pages to different memory
> addresses which would be impossible with a heap::List.
>
> Since ReadOnlySpace no longer uses most of the code from the other
> Spaces it makes sense to simplify its memory allocation to use a simple
> bump pointer and always allocate a new page whenever an allocation
> exceeds the remaining space on the final page.
>
> Change-Id: Iee6d9f96cfb174b4026ee671ee4f897909b38418
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209060
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68137}

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

# Not skipping CQ checks because original CL landed > 1 day ago.

Change-Id: I68c9834872e55eb833be081f8ff99b786bfa9894
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232552
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68211}
      f78d69fa
  43. 03 Jun, 2020 1 commit
    • Dan Elphick's avatar
      [heap] Make ReadOnlySpace use bump pointer allocation · 81c34968
      Dan Elphick authored 
      This changes ReadOnlySpace to no longer be a PagedSpace but instead it
is now a BaseSpace. BasicSpace is a new base class that Space inherits
from and which has no allocation methods and does not dictate how the
pages should be held.

ReadOnlySpace unlike Space holds its pages as a
std::vector<ReadOnlyPage>, where ReadOnlyPage directly subclasses
BasicMemoryChunk, meaning they do not have prev_ and next_ pointers and
cannot be held in a heap::List. This is desirable since with pointer
compression we would like to remap these pages to different memory
addresses which would be impossible with a heap::List.

Since ReadOnlySpace no longer uses most of the code from the other
Spaces it makes sense to simplify its memory allocation to use a simple
bump pointer and always allocate a new page whenever an allocation
exceeds the remaining space on the final page.

Change-Id: Iee6d9f96cfb174b4026ee671ee4f897909b38418
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209060
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68137}
      81c34968
  45. 18 May, 2020 1 commit
  47. 15 May, 2020 1 commit
  49. 14 May, 2020 1 commit
  51. 13 May, 2020 1 commit
  53. 04 May, 2020 1 commit
  55. 24 Jan, 2020 1 commit
  57. 17 Jan, 2020 1 commit
  59. 13 Jan, 2020 1 commit
    • Dominik Inführ's avatar
      [objects] Add ArrayBufferExtension class · 69fda08a
      Dominik Inführ authored 
      This CL adds the ArrayBufferExtension class, which is used to track
JSArrayBuffers in a linked list. The ArrayBufferExtension is going to
replace the ArrayBufferTracker in the future but is currently behind
the v8_enable_array_buffer_extension feature flag.

When enabled, each JSArrayBuffer has a corresponding native-heap
allocated ArrayBufferExtension object. All extensions are currently
tracked in a single linked list. During marking the GC not only
marks the JSArrayBuffer but also its extension object. At the end of
mark-compact the GC iterates all extensions and removes unmarked ones.

Change-Id: I88298be255944d5ae1327c91b0d7f0fdbcd486d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969791Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65724}
      69fda08a
  61. 09 Jan, 2020 1 commit
    • Ulan Degenbaev's avatar
      [heap] Implement per-context marking worklist draining · e27e6fd6
      Ulan Degenbaev authored 
      This changes the marking worklist draining for the main thread
marker and the concurrent marker to use the following algorithm in
per-context mode:
1) Pop an object from the marking worklist.
2) Try to infer the native context that owns the objects.
   This is done using a new NativeContextInferrer class.
3) If the inference is successful, then change the active marking
   worklist to the worklist of the inferred native context.
4) Otherwise, keep the current active marking worklist.
5) Visit the object. Newly discovered objects will be pushed
   onto the active marking worklist.
6) Account the object size for the native context corresponding
   to the active marking worklist.
   This is done using a new NativeContextStats class.

The main property of the algorithm is that each object for which
we couldn't infer the native context is either attributed to
the native context retaining it or is not attributed to any native
context.

Bug: chromium:973627

Change-Id: Ide4ab992275d115279f971d89ace657f4c05e176
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981491
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65663}
      e27e6fd6
  63. 20 Dec, 2019 1 commit
  65. 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
  67. 02 Dec, 2019 1 commit
  69. 27 Nov, 2019 1 commit
  71. 08 Nov, 2019 1 commit
  73. 04 Nov, 2019 1 commit