Skip to content

V
V8
Switch branch/tag
  1. 22 Jun, 2021 1 commit
  3. 11 Jun, 2021 1 commit
    • Dan Elphick's avatar
      [build] Reduce size of inline header cycles · c26965bd
      Dan Elphick authored 
      This removes/replaces header includes with the aim of shrinking the
size of the inline header cycle. Specifically before this CL, there was
a single Strongly-Connected Component comprising 60 header files from
src/objects and src/heap.

Now there are two 2 SCCs. The src/heap SCC has 6 files and depends on
the src/objects SCC, which has 50 files. Additionally some previously
implicit dependencies have been added.

Dependencies calculated using:
git grep "#include \"" *.h *.cc | sed 's/:#include "/ /;s/".*$//' | \
awk 'BEGIN {print "digraph deps {" } END {print "}"} {print "\""$1"\" -> \""$2"\""}'

SCCs found using sccmap from graphviz.

Also removes unused Cell::FromValueAddress method.

Change-Id: Ib19d00ccd14e490ee64d57be4d99b1b3686ac32a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2951734Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75103}
      c26965bd
  5. 08 Jun, 2021 1 commit
  7. 27 Apr, 2021 1 commit
  9. 23 Apr, 2021 1 commit
  11. 09 Apr, 2021 1 commit
  13. 06 Apr, 2021 1 commit
    • Shu-yu Guo's avatar
      Reland^2 "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" · 627b6b2f
      Shu-yu Guo authored 
      This is a reland of e28dadc2

The original failure was due to a stale Win32 bot. The reland failure
was due to idempotent task deduplication returning the exact same
failure. See crbug/1196064

Original change's description:
> [ptr-cage] Rename IsolateRoot to PtrComprCageBase
>
> Currently, IsolateRoot is both the address of the Isolate root and the
> base address of the pointer compression reservation. This CL teases the
> two uses apart by renaming IsolateRoot to PtrComprCageBase.
>
> - In addition to V8_COMPRESS_POINTERS, add a
>   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
>
> - Rename GetIsolate* helpers to GetPtrComprCageBase. When
>   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
>   aliases to GetPtrComprCageBase.
>
> - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
>
> Bug: v8:11460
> Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Auto-Submit: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73790}

Bug: v8:11460
No-Try: true
Tbr: ishell@chromium.org
Tbr: rmcilroy@chromium.org
Change-Id: Id69311cf3267ebe1297fff159de0be48b15b65a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806546Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73795}
      627b6b2f
  15. 05 Apr, 2021 4 commits
    • Shu-yu Guo's avatar
      Revert "Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase"" · 562c4251
      Shu-yu Guo authored 
      This reverts commit 15c78b45.

Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32277/overview

Original change's description:
> Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase"
>
> This is a reland of e28dadc2
>
> Relanding to see if Win32 rel failures from
> https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/overview
> were infra flakes. Could not repro on try bots.
>
> Original change's description:
> > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
> >
> > Currently, IsolateRoot is both the address of the Isolate root and the
> > base address of the pointer compression reservation. This CL teases the
> > two uses apart by renaming IsolateRoot to PtrComprCageBase.
> >
> > - In addition to V8_COMPRESS_POINTERS, add a
> >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
> >
> > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
> >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
> >   aliases to GetPtrComprCageBase.
> >
> > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
> >
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
>
> No-Try: true
> Bug: v8:11460
> Tbr: ishell@chromium.org
> Tbr: rmcilroy@chromium.org
> Change-Id: I0a8c3a48999d6737c8c64d2c2703607f14f3fdd0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806169
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73792}

Bug: v8:11460
Change-Id: Ifee92d622c43a91c15f45ef94ff739237bd2024b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806545
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73793}
      562c4251
    • Shu-yu Guo's avatar
      Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" · 15c78b45
      Shu-yu Guo authored 
      This is a reland of e28dadc2

Relanding to see if Win32 rel failures from
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/overview
were infra flakes. Could not repro on try bots.

Original change's description:
> [ptr-cage] Rename IsolateRoot to PtrComprCageBase
>
> Currently, IsolateRoot is both the address of the Isolate root and the
> base address of the pointer compression reservation. This CL teases the
> two uses apart by renaming IsolateRoot to PtrComprCageBase.
>
> - In addition to V8_COMPRESS_POINTERS, add a
>   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
>
> - Rename GetIsolate* helpers to GetPtrComprCageBase. When
>   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
>   aliases to GetPtrComprCageBase.
>
> - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
>
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>

No-Try: true
Bug: v8:11460
Tbr: ishell@chromium.org
Tbr: rmcilroy@chromium.org
Change-Id: I0a8c3a48999d6737c8c64d2c2703607f14f3fdd0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806169Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73792}
      15c78b45
    • Francis McCabe's avatar
      Revert "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" · 07a9ff4d
      Francis McCabe authored 
      This reverts commit e28dadc2.

Reason for revert: failed test262 tests;; see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/steps?succeeded=true&debug=false

Original change's description:
> [ptr-cage] Rename IsolateRoot to PtrComprCageBase
>
> Currently, IsolateRoot is both the address of the Isolate root and the
> base address of the pointer compression reservation. This CL teases the
> two uses apart by renaming IsolateRoot to PtrComprCageBase.
>
> - In addition to V8_COMPRESS_POINTERS, add a
>   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
>
> - Rename GetIsolate* helpers to GetPtrComprCageBase. When
>   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
>   aliases to GetPtrComprCageBase.
>
> - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
>
> Bug: v8:11460
> Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Auto-Submit: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73790}

Bug: v8:11460
Change-Id: I19d0e28194fcdb28e89f129a7694ca3fe29fa17a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806168
Auto-Submit: Francis McCabe <fgm@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73791}
      07a9ff4d
    • Shu-yu Guo's avatar
      [ptr-cage] Rename IsolateRoot to PtrComprCageBase · e28dadc2
      Shu-yu Guo authored 
      Currently, IsolateRoot is both the address of the Isolate root and the
base address of the pointer compression reservation. This CL teases the
two uses apart by renaming IsolateRoot to PtrComprCageBase.

- In addition to V8_COMPRESS_POINTERS, add a
  V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).

- Rename GetIsolate* helpers to GetPtrComprCageBase. When
  V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
  aliases to GetPtrComprCageBase.

- Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.

Bug: v8:11460
Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73790}
      e28dadc2
  17. 11 Feb, 2021 1 commit
  19. 09 Feb, 2021 1 commit
  21. 01 Feb, 2021 1 commit
  23. 17 Dec, 2020 1 commit
  25. 15 Dec, 2020 1 commit
  27. 03 Dec, 2020 1 commit
    • Leszek Swirski's avatar
      [compiler] Remove disallow scopes · a6f465d4
      Leszek Swirski authored 
      TurboFan creates DisallowHeapAccess scopes, to prevent heap access in
the concurrent parts of the compiler. Then, for parts of the compiler
that do want to access the heap, it either creates Allow* scopes (which
should be avoided since they "punch a hole" in the Disallow* scopes), or
relies on a weakening of Handle::IsDereferenceAllowed which allows
handles owned by a LocalHeap to be dereferenced even if there is a
DisallowHeapDereference scope.

This patch:

  a) Strengthens the implicit requirements around handle dereferencing
     to require a running heap on this thread (either main-thread heap
     or an un-parked, un-safepointed LocalHeap).
  b) Removes the overly strict Disallow scopes in TurboFan, relying
     instead on implicit requirements for allocation/handle
     dereferencing in off-thread code.
  c) Cleans up the "should_disallow_heap_access" predicate to be more
     explicit about what should be disallowed (e.g. property accesses
     can't be computed concurrently)

Change-Id: Icb56b7764913ac17e2db197a70bb189af88a6978
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2554617
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71600}
      a6f465d4
  29. 01 Dec, 2020 1 commit
  31. 30 Nov, 2020 1 commit
  33. 26 Nov, 2020 1 commit
  35. 24 Nov, 2020 1 commit
  37. 20 Nov, 2020 1 commit
  39. 19 Nov, 2020 1 commit
    • Dominik Inführ's avatar
      Reland "[heap] Introduce LocalIsolate for main thread" · dc45361e
      Dominik Inführ authored 
      This is a reland of e95e1b62

After landing https://crrev.com/c/2546682, this CL can be relanded
without changes.

Original change's description:
> [heap] Introduce LocalIsolate for main thread
>
> Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is
> kept alive during the whole lifetime of the Isolate. The main thread
> LocalIsolate starts in the Running state in contrast to the background
> thread LocalIsolates (those start in Parked).
>
> Code paths in Turbofan that used to create a LocalIsolate on the main
> thread can now simply use the main thread LocalIsolate.
>
> LocalIsolate for the main thread will help in reducing differences
> between the main and background threads. The goal is that the main
> thread behaves more like a background thread.
>
> The main thread LocalIsolate should also make it simpler to share code
> between main thread and background threads by using LocalIsolate for
> both.
>
> Bug: v8:10315
> Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71226}

Bug: v8:10315
Change-Id: I418b1217aeac4f3c44a0aa514dea9864f8a58656
TBR: szuend@chromium.org, yangguo@chromium.org, ulan@chromium.org, leszeks@chromium.org, neis@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543399Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71274}
      dc45361e
  41. 17 Nov, 2020 2 commits
    • Michael Achenbach's avatar
      Revert "[heap] Introduce LocalIsolate for main thread" · 9235f258
      Michael Achenbach authored 
      This reverts commit e95e1b62.

Reason for revert:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20debug/23064

Original change's description:
> [heap] Introduce LocalIsolate for main thread
>
> Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is
> kept alive during the whole lifetime of the Isolate. The main thread
> LocalIsolate starts in the Running state in contrast to the background
> thread LocalIsolates (those start in Parked).
>
> Code paths in Turbofan that used to create a LocalIsolate on the main
> thread can now simply use the main thread LocalIsolate.
>
> LocalIsolate for the main thread will help in reducing differences
> between the main and background threads. The goal is that the main
> thread behaves more like a background thread.
>
> The main thread LocalIsolate should also make it simpler to share code
> between main thread and background threads by using LocalIsolate for
> both.
>
> Bug: v8:10315
> Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71226}

TBR=ulan@chromium.org,yangguo@chromium.org,neis@chromium.org,leszeks@chromium.org,szuend@chromium.org,dinfuehr@chromium.org

Change-Id: Ia70b4bfe3b8fa26bf8d6a7dc612a310b0ed54073
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543937Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71228}
      9235f258
    • Dominik Inführ's avatar
      [heap] Introduce LocalIsolate for main thread · e95e1b62
      Dominik Inführ authored 
      Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is
kept alive during the whole lifetime of the Isolate. The main thread
LocalIsolate starts in the Running state in contrast to the background
thread LocalIsolates (those start in Parked).

Code paths in Turbofan that used to create a LocalIsolate on the main
thread can now simply use the main thread LocalIsolate.

LocalIsolate for the main thread will help in reducing differences
between the main and background threads. The goal is that the main
thread behaves more like a background thread.

The main thread LocalIsolate should also make it simpler to share code
between main thread and background threads by using LocalIsolate for
both.

Bug: v8:10315
Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71226}
      e95e1b62
  43. 13 Nov, 2020 1 commit
  45. 02 Nov, 2020 1 commit
  47. 30 Oct, 2020 2 commits
    • Michael Lippautz's avatar
      platform, cppgc: Fix stack handling routines · cfba2e5d
      Michael Lippautz authored 
      - Provide GetRealStackAddressForSlot that deals with ASAN fake stacks
  properly, also accounting for the fact that ASAN gets its real stack
  address in a nested call.
- Fix cppgc on-stack getter.
- Reuse platform routines in global handles.

Bug: chromium:1139914, chromium:1056170
Change-Id: If11a40d543b33edcea220bb70f170ac018e15053
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509594
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70899}
      cfba2e5d
    • Michael Lippautz's avatar
      global-handles: Fix ASAN fake stack handling · aad7b7ff
      Michael Lippautz authored 
      We previously assumed that a fake stack should be mapped back to a
real stack based on fake-stack offsets. This is not correct: Fake and
real stack are disjoint and both contain the corresponding slot
values.

For global handles this means that on-stack handles must be registered
using their real stack frame base to be able to purge them
occasionally based on the current stack address.

When dealing with a slot though, the GC can just dereference the slot
for a value, indeppendent of whether the slot is in a fake or real
frame.

Drive-by: Fix tests that do not want stack handles by creating
handles on heap.

Change-Id: I2c86c8e047bd0d48c24c2642b2b4dba284a93909
Bug: chromium:1139914
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2507720
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70897}
      aad7b7ff
  49. 27 Oct, 2020 1 commit
    • Mike Stanton's avatar
      [TurboFan] Provide concurrent access to feedback vector · 2288b1f6
      Mike Stanton authored 
      This CL provides synchronized get/set to feedback vector slots.
The FeedbackNexus is set up to use order preserving reads when used
on the background thread, and a lock to ensure coherent read
of information for ICKinds with two slots. The main thread takes
the lock on sets.

This test provides patterns to be followed by concurrent TurboFan.

We don't yet access the FeedbackVector on the background thread.
This CL only makes it safe to do so. The next step will come when
the optimizing compiler begins to query the the vector from the
background thread. Currently, with --concurrent-inlining turned on
this is done in bytecode serialization on the main thread. Without
concurrent inlining, it's also done on the main thread, in both
cases using the FeedbackNexus.

Bug: v8:7790
Change-Id: I49d8b8031190f91a0da1c24f375b6b6d8a9fe038
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2276210
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70797}
      2288b1f6
  51. 20 Oct, 2020 1 commit
  53. 13 Oct, 2020 1 commit
  55. 09 Oct, 2020 1 commit
    • Mythri A's avatar
      [handles] Fix is_identical_to to correctly work with Smis · 1f858b3f
      Mythri A authored 
      HandleBase::is_identical_to() is_identical_to in handle base is used to
do the exact comparison by just comparing the locations. When the
locations are different the values are compared. For Smis it
compares 64 bits which might lead to incorrect behaviour. Smis loaded as
a TaggedField has the root address added. It is expexted that we don't
use higher order bits on Smi. Hence, is_identical_to shouldn't use these
bits when comparing Smis. This cl fixes it by comparing the objects
created from the given location. That takes care of correctly comparing
the required bits.

Change-Id: I574dfbea4c1fffc7a9e3a6a10ad7631d40c518ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461743
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70422}
      1f858b3f
  57. 08 Oct, 2020 1 commit
    • Leszek Swirski's avatar
      [serializer] Introduce HandleScopes for object contents · c212d10d
      Leszek Swirski authored 
      Create a HandleScope when serializing an object's contents, to reduce
the number of live handles during serialization. There's only a couple
of cases where these handles have to outlive the serialized contents,
and for these cases we introduce GlobalHandleVector or similar manual
strong root mechanisms.

In particular, backrefs don't actually need to exist as a handle vector
(the object addresses are already referred to by the reference map's
IdentityMap), except for DCHECKs, so this becomes a DEBUG-only global
handle vector.

To support this manual strong-rooting, the HotObjectList is split up
into a strong-rooted find-only class in Serializer, and a Handle
vector in Deserializer.

Bug: chromium:1075999
Change-Id: I586eeeb543e3f6c934c168961b068f2c34e72456
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2449980Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70411}
      c212d10d
  59. 07 Oct, 2020 2 commits
    • Leszek Swirski's avatar
      Reland^4 "[serializer] Allocate during deserialization" · 3c508b38
      Leszek Swirski authored 
      This relands commit 3f4e9bbe.
which was a reland of c4a062a9
which was a reland of 28a30c57
which was a reland of 5d7a29c9

The change had an issue that embedders implementing heap tracing (e.g.
Unified Heap with Blink) could be passed an uninitialized pointer if
marking happened during deserialization of an object containing such a
pointer. Because of the 0xdeadbed0 uninitialized filler value, these
embedders would then receive the value 0xdeadbed0deadbed0 as the
'pointer', and crash on dereference.

There is, however, special handling already for null pointers in heap
tracing, also for dealing with not-yet initialized values. So, we can
make the uninitialized Smi filler be 0x00000000, and that will make such
embedded fields have a nullptr representation, making them follow the
normal uninitialized value bailouts.

In addition, it relands the following dependent changes, which are
relanding unchanged and are followup performance improvements.
Relanding them in the same change should allow for cleaner reverts
should they be needed.

This relands commit 76ad3ab5
[identity-map] Change resize heuristic

This relands commit 77cc96aa
[identity-map] Cache the calculated Hash

This relands commit bee5b996
[serializer] Remove Deserializer::Initialize

This relands commit c8f73f22
[serializer] Cache instance type in PostProcessNewObject

This relands commit 4e7c99ab
[identity-map] Remove double-lookups in IdentityMap

Original change's description:
> Reland^3 "[serializer] Allocate during deserialization"
>
> This is a reland of c4a062a9
> which was a reland of 28a30c57
> which was a reland of 5d7a29c9
>
> Fixes TSAN errors from non-atomic writes in the deserializer. Now all
> writes are (relaxed) atomic.
>
> Original change's description:
> > Reland^2 "[serializer] Allocate during deserialization"
> >
> > This is a reland of 28a30c57
> > which was a reland of 5d7a29c9
> >
> > The crashes were from calling RegisterDeserializerFinished on a null
> > Isolate pointer, for a deserializer that was never initialised
> > (specifically, ReadOnlyDeserializer when ROHeap is shared).
> >
> > Original change's description:
> > > Reland "[serializer] Allocate during deserialization"
> > >
> > > This is a reland of 5d7a29c9
> > >
> > > This reland shuffles around the order of checks in Heap::AllocateRawWith
> > > to not check the new space addresses until it's known that this is a new
> > > space allocation. This fixes an UBSan failure during read-only space
> > > deserialization, which happens before the new space is initialized.
> > >
> > > It also fixes some issues discovered by --stress-snapshot, around
> > > serializing ThinStrings (which are now elided as part of serialization),
> > > handle counts (I bumped the maximum handle count in that check), and
> > > clearing map transitions (the map backpointer field needed a Smi
> > > uninitialized value check).
> > >
> > > Original change's description:
> > > > [serializer] Allocate during deserialization
> > > >
> > > > This patch removes the concept of reservations and a specialized
> > > > deserializer allocator, and instead makes the deserializer allocate
> > > > directly with the Heap's Allocate method.
> > > >
> > > > The major consequence of this is that the GC can now run during
> > > > deserialization, which means that:
> > > >
> > > >   a) Deserialized objects are visible to the GC, and
> > > >   b) Objects that the deserializer/deserialized objects point to can
> > > >      move.
> > > >
> > > > Point a) is mostly not a problem due to previous work in making
> > > > deserialized objects "GC valid", i.e. making sure that they have a valid
> > > > size before any subsequent allocation/safepoint. We now additionally
> > > > have to initialize the allocated space with a valid tagged value -- this
> > > > is a magic Smi value to keep "uninitialized" checks simple.
> > > >
> > > > Point b) is solved by Handlifying the deserializer. This involves
> > > > changing any vectors of objects into vectors of Handles, and any object
> > > > keyed map into an IdentityMap (we can't use Handles as keys because
> > > > the object's address is no longer a stable hash).
> > > >
> > > > Back-references can no longer be direct chunk offsets, so instead the
> > > > deserializer stores a Handle to each deserialized object, and the
> > > > backreference is an index into this handle array. This encoding could
> > > > be optimized in the future with e.g. a second pass over the serialized
> > > > array which emits a different bytecode for objects that are and aren't
> > > > back-referenced.
> > > >
> > > > Additionally, the slot-walk over objects to initialize them can no
> > > > longer use absolute slot offsets, as again an object may move and its
> > > > slot address would become invalid. Now, slots are walked as relative
> > > > offsets to a Handle to the object, or as absolute slots for the case of
> > > > root pointers. A concept of "slot accessor" is introduced to share the
> > > > code between these two modes, and writing the slot (including write
> > > > barriers) is abstracted into this accessor.
> > > >
> > > > Finally, the Code body walk is modified to deserialize all objects
> > > > referred to by RelocInfos before doing the RelocInfo walk itself. This
> > > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
> > > > during a RelocInfo walk.
> > > >
> > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> > > > size rather than byte size -- the size is expected to be tagged-aligned
> > > > anyway, so now we get an extra few bits in the size encoding.
> > > >
> > > > Bug: chromium:1075999
> > > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#70229}

Bug: chromium:1075999
Change-Id: Ib514a4ef16bd02bfb60d046ecbf8fae1ead64a98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2452689
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70366}
      3c508b38
    • Leszek Swirski's avatar
      [ptr-cmpr] Change `const Isolate*` to `IsolateRoot` · 9e26f705
      Leszek Swirski authored 
      Introduce an IsolateRoot class, which encapsulates the root address
needed for pointer decompression. This class is implicitly constructible
from both Isolate* and LocalIsolate*, allowing us to avoid templating
methods that can take both, or awkwardly creating a `const Isolate*`
from a `LocalIsolate*` just for getters.

Change-Id: I6d4b9492409fc7d5b375162e381192cb48c8ba01
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440605
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70365}
      9e26f705
  61. 05 Oct, 2020 3 commits
    • Adam Klein's avatar
      Revert "Reland^3 "[serializer] Allocate during deserialization"" · a10ec2be
      Adam Klein authored 
      This reverts commit 3f4e9bbe, along
with the following dependent changes (reverted to make this a clean revert):
76ad3ab5 [identity-map] Change resize heuristic
77cc96aa [identity-map] Cache the calculated Hash
bee5b996 [serializer] Remove Deserializer::Initialize
c8f73f22 [serializer] Cache instance type in PostProcessNewObject
4e7c99ab [identity-map] Remove double-lookups in IdentityMap

Reason for revert: major crash spike on Canary (https://crbug.com/1135027)

Original change's description:
> Reland^3 "[serializer] Allocate during deserialization"
>
> This is a reland of c4a062a9
> which was a reland of 28a30c57
> which was a reland of 5d7a29c9
>
> Fixes TSAN errors from non-atomic writes in the deserializer. Now all
> writes are (relaxed) atomic.
>
> Original change's description:
> > Reland^2 "[serializer] Allocate during deserialization"
> >
> > This is a reland of 28a30c57
> > which was a reland of 5d7a29c9
> >
> > The crashes were from calling RegisterDeserializerFinished on a null
> > Isolate pointer, for a deserializer that was never initialised
> > (specifically, ReadOnlyDeserializer when ROHeap is shared).
> >
> > Original change's description:
> > > Reland "[serializer] Allocate during deserialization"
> > >
> > > This is a reland of 5d7a29c9
> > >
> > > This reland shuffles around the order of checks in Heap::AllocateRawWith
> > > to not check the new space addresses until it's known that this is a new
> > > space allocation. This fixes an UBSan failure during read-only space
> > > deserialization, which happens before the new space is initialized.
> > >
> > > It also fixes some issues discovered by --stress-snapshot, around
> > > serializing ThinStrings (which are now elided as part of serialization),
> > > handle counts (I bumped the maximum handle count in that check), and
> > > clearing map transitions (the map backpointer field needed a Smi
> > > uninitialized value check).
> > >
> > > Original change's description:
> > > > [serializer] Allocate during deserialization
> > > >
> > > > This patch removes the concept of reservations and a specialized
> > > > deserializer allocator, and instead makes the deserializer allocate
> > > > directly with the Heap's Allocate method.
> > > >
> > > > The major consequence of this is that the GC can now run during
> > > > deserialization, which means that:
> > > >
> > > >   a) Deserialized objects are visible to the GC, and
> > > >   b) Objects that the deserializer/deserialized objects point to can
> > > >      move.
> > > >
> > > > Point a) is mostly not a problem due to previous work in making
> > > > deserialized objects "GC valid", i.e. making sure that they have a valid
> > > > size before any subsequent allocation/safepoint. We now additionally
> > > > have to initialize the allocated space with a valid tagged value -- this
> > > > is a magic Smi value to keep "uninitialized" checks simple.
> > > >
> > > > Point b) is solved by Handlifying the deserializer. This involves
> > > > changing any vectors of objects into vectors of Handles, and any object
> > > > keyed map into an IdentityMap (we can't use Handles as keys because
> > > > the object's address is no longer a stable hash).
> > > >
> > > > Back-references can no longer be direct chunk offsets, so instead the
> > > > deserializer stores a Handle to each deserialized object, and the
> > > > backreference is an index into this handle array. This encoding could
> > > > be optimized in the future with e.g. a second pass over the serialized
> > > > array which emits a different bytecode for objects that are and aren't
> > > > back-referenced.
> > > >
> > > > Additionally, the slot-walk over objects to initialize them can no
> > > > longer use absolute slot offsets, as again an object may move and its
> > > > slot address would become invalid. Now, slots are walked as relative
> > > > offsets to a Handle to the object, or as absolute slots for the case of
> > > > root pointers. A concept of "slot accessor" is introduced to share the
> > > > code between these two modes, and writing the slot (including write
> > > > barriers) is abstracted into this accessor.
> > > >
> > > > Finally, the Code body walk is modified to deserialize all objects
> > > > referred to by RelocInfos before doing the RelocInfo walk itself. This
> > > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
> > > > during a RelocInfo walk.
> > > >
> > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> > > > size rather than byte size -- the size is expected to be tagged-aligned
> > > > anyway, so now we get an extra few bits in the size encoding.
> > > >
> > > > Bug: chromium:1075999
> > > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#70229}
> > >
> > > Bug: chromium:1075999
> > > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#70267}
> >
> > Tbr: jgruber@chromium.org,ulan@chromium.org
> > Bug: chromium:1075999
> > Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70279}
>
> Tbr: jgruber@chromium.org,ulan@chromium.org
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng
> Bug: chromium:1075999
> Change-Id: I0b9b11644aebc4cc8b07c62a0f765b24e4d73d89
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445872
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70288}

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

Bug: chromium:1075999, chromium:1135027
Change-Id: I5d0d9e49c0302d94ff7291834f5f18e7a0839eb7
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2451030Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70328}
      a10ec2be
    • Omer Katz's avatar
      cppgc: Thread safe JSMember · f6bc6b6d
      Omer Katz authored 
      Make all writes to JSMember.val_ atomic and atomically check for
emptiness in Trace.

Bug: chromium:1056170
Change-Id: Ia7034b9318df081aa61c9b6664903dd4f73402a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431569Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70309}
      f6bc6b6d
    • Leszek Swirski's avatar
      [identity-map] Remove double-lookups in IdentityMap · 4e7c99ab
      Leszek Swirski authored 
      Remove the pattern of calling 'Find' followed by 'Set' for IdentityMap,
with a single 'FindOrInsert' that explicitly returns whether an existing
entry was found, or the entry was inserted. This replaces 'Get', which
would return either an initialised or uninitialised entry (and callers
would rely on default initialisation to check this).

Also replace 'Set' with 'Insert', which explicitly requires that the
element didn't exist before. This matches expectations where it was
used (where those weren't replaced wholesale with 'FindOrInsert'), and
makes the naming consistent with 'FindOrInsert'.

Change-Id: I8fb76f4ac14fb92b88474965aafb1ace5fb79145
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2443135
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70300}
      4e7c99ab
  63. 02 Oct, 2020 1 commit
    • Leszek Swirski's avatar
      Reland^3 "[serializer] Allocate during deserialization" · 3f4e9bbe
      Leszek Swirski authored 
      This is a reland of c4a062a9
which was a reland of 28a30c57
which was a reland of 5d7a29c9

Fixes TSAN errors from non-atomic writes in the deserializer. Now all
writes are (relaxed) atomic.

Original change's description:
> Reland^2 "[serializer] Allocate during deserialization"
>
> This is a reland of 28a30c57
> which was a reland of 5d7a29c9
>
> The crashes were from calling RegisterDeserializerFinished on a null
> Isolate pointer, for a deserializer that was never initialised
> (specifically, ReadOnlyDeserializer when ROHeap is shared).
>
> Original change's description:
> > Reland "[serializer] Allocate during deserialization"
> >
> > This is a reland of 5d7a29c9
> >
> > This reland shuffles around the order of checks in Heap::AllocateRawWith
> > to not check the new space addresses until it's known that this is a new
> > space allocation. This fixes an UBSan failure during read-only space
> > deserialization, which happens before the new space is initialized.
> >
> > It also fixes some issues discovered by --stress-snapshot, around
> > serializing ThinStrings (which are now elided as part of serialization),
> > handle counts (I bumped the maximum handle count in that check), and
> > clearing map transitions (the map backpointer field needed a Smi
> > uninitialized value check).
> >
> > Original change's description:
> > > [serializer] Allocate during deserialization
> > >
> > > This patch removes the concept of reservations and a specialized
> > > deserializer allocator, and instead makes the deserializer allocate
> > > directly with the Heap's Allocate method.
> > >
> > > The major consequence of this is that the GC can now run during
> > > deserialization, which means that:
> > >
> > >   a) Deserialized objects are visible to the GC, and
> > >   b) Objects that the deserializer/deserialized objects point to can
> > >      move.
> > >
> > > Point a) is mostly not a problem due to previous work in making
> > > deserialized objects "GC valid", i.e. making sure that they have a valid
> > > size before any subsequent allocation/safepoint. We now additionally
> > > have to initialize the allocated space with a valid tagged value -- this
> > > is a magic Smi value to keep "uninitialized" checks simple.
> > >
> > > Point b) is solved by Handlifying the deserializer. This involves
> > > changing any vectors of objects into vectors of Handles, and any object
> > > keyed map into an IdentityMap (we can't use Handles as keys because
> > > the object's address is no longer a stable hash).
> > >
> > > Back-references can no longer be direct chunk offsets, so instead the
> > > deserializer stores a Handle to each deserialized object, and the
> > > backreference is an index into this handle array. This encoding could
> > > be optimized in the future with e.g. a second pass over the serialized
> > > array which emits a different bytecode for objects that are and aren't
> > > back-referenced.
> > >
> > > Additionally, the slot-walk over objects to initialize them can no
> > > longer use absolute slot offsets, as again an object may move and its
> > > slot address would become invalid. Now, slots are walked as relative
> > > offsets to a Handle to the object, or as absolute slots for the case of
> > > root pointers. A concept of "slot accessor" is introduced to share the
> > > code between these two modes, and writing the slot (including write
> > > barriers) is abstracted into this accessor.
> > >
> > > Finally, the Code body walk is modified to deserialize all objects
> > > referred to by RelocInfos before doing the RelocInfo walk itself. This
> > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
> > > during a RelocInfo walk.
> > >
> > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> > > size rather than byte size -- the size is expected to be tagged-aligned
> > > anyway, so now we get an extra few bits in the size encoding.
> > >
> > > Bug: chromium:1075999
> > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#70229}
> >
> > Bug: chromium:1075999
> > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70267}
>
> Tbr: jgruber@chromium.org,ulan@chromium.org
> Bug: chromium:1075999
> Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70279}

Tbr: jgruber@chromium.org,ulan@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng
Bug: chromium:1075999
Change-Id: I0b9b11644aebc4cc8b07c62a0f765b24e4d73d89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445872
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70288}
      3f4e9bbe