1. 03 Mar, 2022 1 commit
  2. 28 Feb, 2022 1 commit
    • Nikolaos Papaspyrou's avatar
      heap: Deprecate counters for GC UMA histograms · d0af9947
      Nikolaos Papaspyrou authored
      The following histograms have been deprecated, as they are superseded
      by V8.GC.Cycle.*.Young or not needed anymore (next to each, the
      corresponding isolate counter):
      
      - V8.GCScavenger (gc_scavenger)
      - V8.GCScavengerBackground (gc_scavenger_background)
      - V8.GCScavengeReason (scavenge_reason)
      - V8.GCScavengerForeground (gc_scavenger_foreground)
      - V8.GCBackgroundScavenger (background_scavenger)
      - V8.GCMarkCompactor (gc_mark_compactor)
      
      This CL removes the corresponding instrumentation in the code and the
      isolate counters.
      
      Bug: chromium:1154636
      Bug: chromium:1299555
      Change-Id: I62d28ff60ef47a058fe148c7855af8e2c1cc0aed
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3487548Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79308}
      d0af9947
  3. 24 Feb, 2022 1 commit
  4. 23 Feb, 2022 1 commit
    • Anton Bikineev's avatar
      cppgc: young-gen: Always execute custom weak callbacks for old objects · 3984ddc0
      Anton Bikineev authored
      Custom callbacks assume that untraced pointers always point to valid,
      not freed objects. They must make sure that upon callback completion no
      UntracedMembers point to an unreachable object. This may not hold true
      if a custom callback for an old object operates with a reference to a
      young object that was freed on a minor collection cycle. To maintain
      the mentioned invariant, the CL calls custom callbacks for old objects
      on every minor collection cycle.
      
      The alternative options could be:
      1) Replacing all UntracedMembers with WeakMembers, since WeakMember
         supports tracing and the barrier.
      2) Emitting the generational barrier for UntracedMember + tracing
         UntracedMember on minor collection cycles.
      The first option requires changing multiple use sites and can bring some
      performance regression. The second option requires changing the GC logic
      and the semantics of UntracedMember.
      
      Bug: chromium:1029379
      Change-Id: I9bb89e4787daf05990feed374dceca940be7be63
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3472499Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Anton Bikineev <bikineev@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79221}
      3984ddc0
  5. 22 Feb, 2022 2 commits
  6. 20 Feb, 2022 1 commit
  7. 18 Feb, 2022 1 commit
  8. 17 Feb, 2022 2 commits
    • Milad Fa's avatar
      Fix compilation error on gcc · 9bfa2aa6
      Milad Fa authored
      https://crrev.com/c/3471558 is causing the following compilation
      error on gcc:
      ```
      error: suggest explicit braces to avoid ambiguous 'else'
      ```
      
      Bug: chromium:1298417
      Change-Id: I84a34603664c5ee148cc9ea282c0f8c53319b6d8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3472403Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#79154}
      9bfa2aa6
    • Benoît Lizé's avatar
      [heap/cppgc] Disable guard pages on ARM64 macOS · 8f3c3419
      Benoît Lizé authored
      Guard pages are 4k areas at the beginning and end of each oilpan page
      (128kiB) which are meant to be inaccessible. However on ARM64 macOS, the
      OS page size is 16kiB, meaning that these are not inaccessible. But we
      do pay for these, as they are part of the first and last OS
      page. Meaning that we effectively waste 2 * 4kiB = 6.25% of each Oilpan
      page.
      
      Since these are not serving their purpose, disable them on this
      platform. Another fix could be to make the guard page 16kiB, but given
      that the entire oilpan page is 128kiB, this may have adverse effects on
      e.g. fragmentation.
      
      Note that this doesn't regress security, as the regions were never
      protected to begin with on this platform.
      
      Bug: chromium:1298417
      Change-Id: Iad5d05670962780e6d1eeab2bb8a331deb7aa1f3
      Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3471558Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Benoit Lize <lizeb@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79151}
      8f3c3419
  9. 14 Feb, 2022 2 commits
  10. 11 Feb, 2022 1 commit
  11. 03 Feb, 2022 2 commits
  12. 02 Feb, 2022 4 commits
    • Nikolaos Papaspyrou's avatar
      heap: Fix the tracing of GC cycles · 73a1c635
      Nikolaos Papaspyrou authored
      Conceptually, a full GC cycle completes when the sweeping phase is
      finished. As sweeping is performed concurrently, this happens after
      Heap::CollectGarbage has returned and, at the latest, before the next
      full GC cycle begins. However, an arbitrary number of young GC cycles
      may happen in the meantime. Tracing information for the sweeping phase
      must be added to the corresponding full GC cycle event. Until now, this
      was not done correctly: this information was added to the GCTracer's
      current event and could thus be attributed to a subsequent young or full
      GC cycle.
      
      This CL introduces methods GCTracer::(Start|Stop)Cycle to delimit a
      cycle (still allowing for full GC cycles to be interrupted by young GC
      cycles). These methods are different from (Start|Stop)ObservablePause,
      which delimit the observable pause of each GC. The events of "pending"
      full GC cycles are kept until they are properly amended and reported,
      when the sweeping phase is finished.
      
      This is a reland of 4ad20bff
      which was reviewed here: https://crrev.com/3404733
      
      Bug: v8:12503
      Bug: chromium:1154636
      Change-Id: Icc315b53cff1f3b19b8efe49db34340a5608bcd2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3432211Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78911}
      73a1c635
    • Leszek Swirski's avatar
      Revert "heap: Fix the tracing of GC cycles" · 10e811c4
      Leszek Swirski authored
      This reverts commit 4ad20bff.
      
      Reason for revert: New test seems to be failing on TSAN/incremental marking stress (https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/6346/overview)
      
      Original change's description:
      > heap: Fix the tracing of GC cycles
      >
      > Conceptually, a full GC cycle completes when the sweeping phase is
      > finished. As sweeping is performed concurrently, this happens after
      > Heap::CollectGarbage has returned and, at the latest, before the next
      > full GC cycle begins. However, an arbitrary number of young GC cycles
      > may happen in the meantime. Tracing information for the sweeping phase
      > must be added to the corresponding full GC cycle event. Until now, this
      > was not done correctly: this information was added to the GCTracer's
      > current event and could thus be attributed to a subsequent young or full
      > GC cycle.
      >
      > This CL introduces methods GCTracer::(Start|Stop)Cycle to delimit a
      > cycle (still allowing for full GC cycles to be interrupted by young GC
      > cycles). These methods are different from (Start|Stop)ObservablePause,
      > which delimit the observable pause of each GC. The events of "pending"
      > full GC cycles are kept until they are properly amended and reported,
      > when the sweeping phase is finished.
      >
      > Bug: chromium:1154636
      > Change-Id: I2fbc65d4807c78656d4abc8c451043f6f86211b1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3404733
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78905}
      
      Bug: chromium:1154636
      Change-Id: Id6688cfe982f9d8159c66d715b7079782a371bed
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3431489
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Owners-Override: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78908}
      10e811c4
    • Nikolaos Papaspyrou's avatar
      heap: Fix the tracing of GC cycles · 4ad20bff
      Nikolaos Papaspyrou authored
      Conceptually, a full GC cycle completes when the sweeping phase is
      finished. As sweeping is performed concurrently, this happens after
      Heap::CollectGarbage has returned and, at the latest, before the next
      full GC cycle begins. However, an arbitrary number of young GC cycles
      may happen in the meantime. Tracing information for the sweeping phase
      must be added to the corresponding full GC cycle event. Until now, this
      was not done correctly: this information was added to the GCTracer's
      current event and could thus be attributed to a subsequent young or full
      GC cycle.
      
      This CL introduces methods GCTracer::(Start|Stop)Cycle to delimit a
      cycle (still allowing for full GC cycles to be interrupted by young GC
      cycles). These methods are different from (Start|Stop)ObservablePause,
      which delimit the observable pause of each GC. The events of "pending"
      full GC cycles are kept until they are properly amended and reported,
      when the sweeping phase is finished.
      
      Bug: chromium:1154636
      Change-Id: I2fbc65d4807c78656d4abc8c451043f6f86211b1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3404733Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78905}
      4ad20bff
    • Anton Bikineev's avatar
      cppgc: young-gen: Prepare infra for young generation · 8370387f
      Anton Bikineev authored
      The CL does following:
      1) Makes sure young generation works and tests pass;
      2) Provides CollectGarbageInYoungGenerationForTesting() that is needed
         to support remaining tests in Blink;
      3) Moved cppgc_enable_young_generation GN flag to v8.gni to refer to it
         from Blink;
      4) Bails out from marking TracedReferences in UnifiedHeapMarkingState;
      5) Disables (temporarily) prompt freeing for young generation;
      6) Fixes remembered set visitation for nullptr|kSentinel slots.
      
      Bug: chromium:1029379
      Change-Id: I5165fa22c8a0eaa708ef7a35a9978cb12e1cb13e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3429202Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Auto-Submit: Anton Bikineev <bikineev@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78901}
      8370387f
  13. 21 Jan, 2022 1 commit
  14. 20 Jan, 2022 1 commit
  15. 14 Jan, 2022 1 commit
    • Michael Lippautz's avatar
      Reland "cppgc-js,heap: Implement snapshots for embedder fields" · 804aaa5c
      Michael Lippautz authored
      This is a reland of 142dd775
      
      Original change's description:
      > cppgc-js,heap: Implement snapshots for embedder fields
      >
      > https://crrev.com/c/3293410 added concurrent processing of C++ objects
      > found through V8 embedder fields. The CL missed that those embedder
      > fields are not read atomically from JS objects. The problem is that
      > embedder fields are only aligned to kTaggedSize on builds with pointer
      > compression and are as such mis-aligned for atomic ops. This is not a
      > problem for on-heap values as the upper 32bits are anyways computed
      > from the cage. Is is a problem for generic C++ values though, as they
      > are used with Oilpan.
      >
      > This CL adds the standard marker snapshot protocol for embedder fields.
      >
      > Marker:
      > 1. Snapshot embedder fields
      > 2. Try to mark host object
      > 3. On success: process snapshot
      >
      > Main thread:
      > 1. On setting embedder fields mark the object black first
      > 2. Emit a write barrier for the embedder fields
      >
      > This will get simpler with the heap sandbox that uses a separate table
      > for embedder fields. Once the sandbox is the default configuration, we
      > 	can use it as dependency for the concurrent fast path.
      >
      > Bug: chromium:1285706
      > Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78604}
      
      Bug: chromium:1285706
      Change-Id: I024e50fc0757fbcd13cb9ffde027dff55f99d25c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386600Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78631}
      804aaa5c
  16. 13 Jan, 2022 2 commits
    • Leszek Swirski's avatar
      Revert "cppgc-js,heap: Implement snapshots for embedder fields" · 7d4e3d35
      Leszek Swirski authored
      This reverts commit 142dd775.
      
      Reason for revert: TSAN breaks: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/6113/overview
      
      Original change's description:
      > cppgc-js,heap: Implement snapshots for embedder fields
      >
      > https://crrev.com/c/3293410 added concurrent processing of C++ objects
      > found through V8 embedder fields. The CL missed that those embedder
      > fields are not read atomically from JS objects. The problem is that
      > embedder fields are only aligned to kTaggedSize on builds with pointer
      > compression and are as such mis-aligned for atomic ops. This is not a
      > problem for on-heap values as the upper 32bits are anyways computed
      > from the cage. Is is a problem for generic C++ values though, as they
      > are used with Oilpan.
      >
      > This CL adds the standard marker snapshot protocol for embedder fields.
      >
      > Marker:
      > 1. Snapshot embedder fields
      > 2. Try to mark host object
      > 3. On success: process snapshot
      >
      > Main thread:
      > 1. On setting embedder fields mark the object black first
      > 2. Emit a write barrier for the embedder fields
      >
      > This will get simpler with the heap sandbox that uses a separate table
      > for embedder fields. Once the sandbox is the default configuration, we
      > 	can use it as dependency for the concurrent fast path.
      >
      > Bug: chromium:1285706
      > Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78604}
      
      Bug: chromium:1285706
      Change-Id: If1976c0356f450fc068aa4dcc39fb9a0d5417a40
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386598
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Owners-Override: Leszek Swirski <leszeks@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/main@{#78605}
      7d4e3d35
    • Michael Lippautz's avatar
      cppgc-js,heap: Implement snapshots for embedder fields · 142dd775
      Michael Lippautz authored
      https://crrev.com/c/3293410 added concurrent processing of C++ objects
      found through V8 embedder fields. The CL missed that those embedder
      fields are not read atomically from JS objects. The problem is that
      embedder fields are only aligned to kTaggedSize on builds with pointer
      compression and are as such mis-aligned for atomic ops. This is not a
      problem for on-heap values as the upper 32bits are anyways computed
      from the cage. Is is a problem for generic C++ values though, as they
      are used with Oilpan.
      
      This CL adds the standard marker snapshot protocol for embedder fields.
      
      Marker:
      1. Snapshot embedder fields
      2. Try to mark host object
      3. On success: process snapshot
      
      Main thread:
      1. On setting embedder fields mark the object black first
      2. Emit a write barrier for the embedder fields
      
      This will get simpler with the heap sandbox that uses a separate table
      for embedder fields. Once the sandbox is the default configuration, we
      	can use it as dependency for the concurrent fast path.
      
      Bug: chromium:1285706
      Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78604}
      142dd775
  17. 12 Jan, 2022 2 commits
    • Dominik Inführ's avatar
      Reland "[heap] Optimize time to reach global safepoint" · 93f28d16
      Dominik Inführ authored
      This is a reland of 86038ecf
      
      Compared to the previous CL this one is adding a TSAN suppression
      for GlobalSafepoint::EnterSafepointScope. local_heaps_mutex_ of client
      isolates may be locked in any order. This would be detected by TSAN as a
      potential race. Add some additional DCHECKs to compensate for that
      missing test coverage.
      
      As a cleanup this CL also removes the unused methods ContainsLocalHeap()
      and ContainsAnyLocalHeap() from LocalHeap.
      
      Original change's description:
      > [heap] Optimize time to reach global safepoint
      >
      > Initial support for global safepoints kept it simple by entering a
      > safepoint for each of them one after another. This means
      > time-to-global-safepoint is the sum of all time-to-safepoint operations.
      > We can improve this slightly by splitting up the safepoint iteration
      > into two operations:
      >
      > 1) Initiate safepoint lock (locks local_heaps_mutex_, arms the barrier
      >    and sets SafepointRequested flag for all client threads)
      > 2) Block until all runnning client threads reach a safepoint
      >
      > We now perform operation 1) for all clients first and only then start
      > with operation 2).
      >
      > Bug: v8:11708
      > Change-Id: Iaafd3c6d70bcf7026f722633e9250b04148b3da6
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310910
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78308}
      
      Bug: v8:11708, v8:12492
      Change-Id: I7087ba23c08f2d4edb9b632eef3c218fc76342e7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328786Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78583}
      93f28d16
    • Dominik Inführ's avatar
      [heap] Refactor MemoryAllocator · 88ecbf26
      Dominik Inführ authored
      This CL doesn't change behavior, only refactors MemoryAllocator:
      
      * De-templatify class, MemoryAllocator is used on slow path and doesn't
        really need templates for performance.
      * Rename FreeMode names
      * Move methods into private section of class
      
      Change-Id: I7894fba956dcd7aa78ad0284d0924662fef4acae
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379812Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78580}
      88ecbf26
  18. 27 Dec, 2021 1 commit
    • Omer Katz's avatar
      cppgc-js, heap: Concurrently push references from v8 to Oilpan · d10f61e1
      Omer Katz authored
      Included in this CL:
      (*) Introduce CppMarkingState that V8 should use to push references to
          Oilpan. CppMarkingState allocates its own Worklist::Locals to
          support concurrent updates from V8.
      (*) Split Oilpan MarkingWorklist object to form a base class used by
          CppMarkingState.
      (*) Remove MarkerFactory and split marking initialization. Marking
          worklists should already be initialized when V8 initializes
          visitors. For incremental marking, this requires splitting
          marking initialization and marking start.
      (*) Drive-by: Mark JSObject::IsApiWrapper and
          JSObject::IsDroppableApiWrapper as const.
      
      Bug: v8:12407
      Change-Id: I35cc816343da86f69a68306204675720e9b3913f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293410Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78446}
      d10f61e1
  19. 15 Dec, 2021 1 commit
    • Samuel Groß's avatar
      V8 Sandbox rebranding · 277fdd1d
      Samuel Groß authored
      This CL renames a number of things related to the V8 sandbox.
      Mainly, what used to be under V8_HEAP_SANDBOX is now under
      V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage
      is now simply the V8 Sandbox:
      
      V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX
      V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS
      V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS
      V8VirtualMemoryCage => Sandbox
      CagedPointer => SandboxedPointer
      fake cage => partially reserved sandbox
      src/security => src/sandbox
      
      This naming scheme should simplify things: the sandbox is now the large
      region of virtual address space inside which V8 mainly operates and
      which should be considered untrusted. Mechanisms like sandboxed pointers
      are then used to attempt to prevent escapes from the sandbox (i.e.
      corruption of memory outside of it). Furthermore, the new naming scheme
      avoids the confusion with the various other "cages" in V8, in
      particular, the VirtualMemoryCage class, by dropping that name entirely.
      
      Future sandbox features are developed under their own V8_SANDBOX_X flag,
      and will, once final, be merged into V8_SANDBOX. Current future features
      are sandboxed external pointers (using the external pointer table), and
      sandboxed pointers (pointers guaranteed to point into the sandbox, e.g.
      because they are encoded as offsets). This CL then also introduces a new
      build flag, v8_enable_sandbox_future, which enables all future features.
      
      Bug: v8:10391
      Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78384}
      277fdd1d
  20. 09 Dec, 2021 1 commit
  21. 08 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler] Introduce ReusableUnoptimizedCompileState · b3e1eb0c
      Leszek Swirski authored
      Introduce a ReusableUnoptimizedCompileState class, passed to ParseInfo,
      which stores a couple of pointers and most importantly the Zone and
      AstValueFactory of the parse. This allows the Zone and AstValueFactory
      to be reused across multiple parses, rather than re-initialising
      per-Parse.
      
      With this, we can amend the LazyCompileDispatcher to initialise one
      LocalIsolate, Zone and AstValueFactory per background thread loop,
      rather than one per compile task, which allows us to reduce per-task
      costs and re-use the AstValueFactory's string table and previous String
      internalizations.
      
      Change-Id: Ia0e29c4e31fbe29af57674ebb10916865d38b2ce
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313106Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78289}
      b3e1eb0c
  22. 07 Dec, 2021 1 commit
  23. 04 Dec, 2021 1 commit
    • Samuel Groß's avatar
      Introduce VirtualAddressSpace interface · a7cb30b0
      Samuel Groß authored
      This interface is meant to eventually replace the existing
      v8::PageAllocator interface. Beyond general refactoring of the
      PageAllocator APIs, the new interface now supports the concept of
      (contiguous) address space reservations, which previously had to be
      implemented through page allocations. These reservations now make better
      use of provided OS primitives on Fuchsia (VMARs) and Windows
      (placeholder mappings) and can be used to back many of the cages and
      virtual memory regions that V8 creates.
      
      The new interface is not yet stable and may change at any time without
      deprecating the old version first.
      
      Bug: chromium:1218005
      Change-Id: I295253c42e04cf311393c5dab9f8c06bd7451ce3
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3301475
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78235}
      a7cb30b0
  24. 02 Dec, 2021 1 commit
  25. 29 Nov, 2021 4 commits
  26. 26 Nov, 2021 2 commits
  27. 25 Nov, 2021 1 commit