1. 13 May, 2022 1 commit
  2. 29 Apr, 2022 1 commit
    • Anton Bikineev's avatar
      cppgc: young-gen: Add runtime option for young generation · c7dfa3fa
      Anton Bikineev authored
      The CL introduces a new option --cppgc-young-generation. This option
      can't be enabled statically, because V8 options are parsed after heap
      initialization. The CL changes minor GC so that it can be enabled
      dynamically. The way it works is as follows:
      - the user calls YoungGenerationEnabler::Enable();
      - a heap checks in the next atomic pause whether the flag was enabled;
      - if so, the heap enables young generation for itself.
      
      To avoid barrier regressions without young-generation enabled, the CL changes the meaning of the global flag is-any-incremental-or-concurrent-marking to is-barrier-enabled.
      
      The runtime option would enable us to test young generation on try-
      and performance-bots.
      
      Bug: chromium:1029379
      Change-Id: I664cccdcd208225ffcbf9901f1284b56d088c5c3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607993
      Commit-Queue: Anton Bikineev <bikineev@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80274}
      c7dfa3fa
  3. 23 Mar, 2022 1 commit
  4. 25 Feb, 2022 1 commit
  5. 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
  6. 22 Feb, 2022 1 commit