Skip to content

V
V8
Switch branch/tag
  1. 20 May, 2019 2 commits
  3. 17 May, 2019 1 commit
  5. 16 May, 2019 3 commits
  7. 15 May, 2019 1 commit
  9. 14 May, 2019 2 commits
  11. 09 May, 2019 3 commits
  13. 08 May, 2019 2 commits
  15. 03 May, 2019 1 commit
    • Maciej Goszczycki's avatar
      Revert "[heap] Set read-only space's and its pages' heap_ to null." · fa4b433f
      Maciej Goszczycki authored 
      This reverts commit 964edc25.

Reason for revert: chromium:959190

Original change's description:
> [heap] Set read-only space's and its pages' heap_ to null.
>
> Various small changes are required to enable this.
>
> HeapObject::GetReadOnlyRoots no longer uses the Space's heap when
> possible (see comment in ReadOnlyHeap::GetReadOnlyRoots definition).
> This requires that ReadOnlyRoots be construct-able using a raw pointer
> to the read-only space's roots array.
>
> Global read-only heap state is now cleared by tests where appropriate
> and extra DCHECKs in ReadOnlyHeap::SetUp should make catching future
> issues easier.
>
> String padding is now always cleared just before read-only space is
> sealed when not deserializing.
>
> Change-Id: I7d1db1c11567be5df06ff7066f3a699125f8b372
> Bug: v8:7464
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535830
> Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61188}

TBR=ulan@chromium.org,hpayer@chromium.org,delphick@chromium.org,goszczycki@google.com

Change-Id: I53cecf3976dfeabae309040313351385f651f010
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7464, chromium:959190
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591608Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61217}
      fa4b433f
  17. 02 May, 2019 3 commits
    • Maciej Goszczycki's avatar
      [heap] Set read-only space's and its pages' heap_ to null. · 964edc25
      Maciej Goszczycki authored 
      Various small changes are required to enable this.

HeapObject::GetReadOnlyRoots no longer uses the Space's heap when
possible (see comment in ReadOnlyHeap::GetReadOnlyRoots definition).
This requires that ReadOnlyRoots be construct-able using a raw pointer
to the read-only space's roots array.

Global read-only heap state is now cleared by tests where appropriate
and extra DCHECKs in ReadOnlyHeap::SetUp should make catching future
issues easier.

String padding is now always cleared just before read-only space is
sealed when not deserializing.

Change-Id: I7d1db1c11567be5df06ff7066f3a699125f8b372
Bug: v8:7464
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535830
Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61188}
      964edc25
    • Maciej Goszczycki's avatar
      Reland "[heap] Skip ro-space from heap iterators, add CombinedHeapIterator." · 9c062093
      Maciej Goszczycki authored 
      Code relocation info is now always allocated in old-space. Before relocation
info allocated for placeholders and builtins (which get replaced with
trampolines in nosnap builds) would become unreachable. Since read-only space
is not GCed and ReadOnlyHeapIterator doesn't check for reachability,
ValidateSnapshot would fail finding unreachable objects returned by
ReadOnlyHeapIterator.

Because trampoline relocation info gets replaced with canonical one, this only
affects no-embdded-builtins nosnap builds, which don't get much benefit from
read-only relocation info anyway.

A new check has been added to the read-only deserializer to verify that every
read-only object is reachable at mksnapshot-time.

The CombinedHeapIterator iteration order was changed to iterate over
read-only space first, because that's how HeapIterator worked.

This is a reland of 3d1d8eae

Original change's description:
> [heap] Skip ro-space from heap iterators, add CombinedHeapIterator.
>
> Read-only space sharing requires an iterator independent of heap. This
> also enables future removal of read-only space from heap.
>
> Bug: v8:7464
> Change-Id: Ia07a9369494ea2c547d12c01ffa1d7b8b6bbeabc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552795
> Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60819}

Bug: v8:7464
Change-Id: I49ae070955b77956962334a84f762ab29052d5ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1566513Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
Cr-Commit-Position: refs/heads/master@{#61185}
      9c062093
    • Hannes Payer's avatar
      [heap] Add a page-based code object registry. · e09fbbd1
      Hannes Payer authored 
      The registry right now has no users. In a follow-up CL I will
remove the skip list for code pages and make users of the skip
list use the registry.

Bug: v8:9093
Change-Id: I23a2b9e0d4158e2ffa89626e71f58d3bb5a41201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593074Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61184}
      e09fbbd1
  19. 30 Apr, 2019 2 commits
  21. 29 Apr, 2019 6 commits
  23. 26 Apr, 2019 1 commit
  25. 24 Apr, 2019 2 commits
  27. 23 Apr, 2019 2 commits
  29. 12 Apr, 2019 3 commits
  31. 29 Mar, 2019 1 commit
  33. 25 Mar, 2019 1 commit
    • Mythri's avatar
      [lite] Allocate feedback vectors lazily · 7629afdb
      Mythri authored 
      Allocate feedback vectors lazily when the function's interrupt budget has
reached a specified threshold. This cl introduces a new field in the
ClosureFeedbackCellArray to track the interrupt budget for allocating
feedback vectors. Using the interrupt budget on the bytecode array could
cause problems when there are closures across native contexts and we may
delay allocating feedback vectors in one of them causing unexpected
performance cliffs. In the long term we may want to remove interrupt budget
from bytecode array and use context specific budget for tiering up decisions
as well.

Bug: v8:8394
Change-Id: Ia8fbb71f5e8543a92f14c44aa762973da82d445c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520719
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60450}
      7629afdb
  35. 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
  37. 18 Mar, 2019 1 commit
  39. 12 Mar, 2019 1 commit
  41. 11 Mar, 2019 1 commit