1. 24 Feb, 2022 1 commit
  2. 23 Feb, 2022 1 commit
    • Jakob Gruber's avatar
      [safepoints] Various refactors · c7e47c30
      Jakob Gruber authored
      A collection of smallish cleanups and improvements for safepoints.
      
      Maintainability:
      - The class names were not very clear; move Safepoint inside
        SafepointTableBuilder to clarify that this wrapper class is used
        during codegen.
      - Rename DefinePointerSlot/DefineRegister to
        DefineTaggedStackSlot/DefineTaggedRegister for clarity.
      - Use named constants instead of -1.
      - DefineTaggedRegister has no connection to kNoDeoptIndex, remove
        the DCHECK and comment.
      - Remove the unused kNumSafepointRegisters constant + other dead code.
      - Small clarifications in CommonFrame::IterateCompiledFrame.
      - Rename has_safepoint_info to uses_safepoint_table and refactor s.t.
        `stack_slots` can be used when `uses_safepoint_table == false`. In
        this case it just returns 0.
      
      Perf:
      - During codegen, represent stack slots as a growable bit vector
        instead of a list of int indices. Extend GrowableBitVector
        functionality to support the above.
      - Track the minimum index instead of iterating all stack slots in
        all safepoints before encoding.
      
      Bug: v8:7700
      Change-Id: If409bc42c825d47fc0074fce51e3b963fd080806
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3483659Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79233}
      c7e47c30
  3. 21 Feb, 2022 2 commits
  4. 10 Feb, 2022 1 commit
  5. 07 Feb, 2022 1 commit
  6. 31 Jan, 2022 1 commit
  7. 20 Jan, 2022 1 commit
  8. 16 Dec, 2021 1 commit
  9. 14 Dec, 2021 4 commits
  10. 30 Nov, 2021 2 commits
  11. 18 Nov, 2021 2 commits
  12. 11 Nov, 2021 1 commit
    • Seth Brenith's avatar
      Fix crashes introduced by "Fix leaks due to deoptimization literals" · 6e9f5de2
      Seth Brenith authored
      My previous change https://crrev.com/c/3160299 introduced a runtime
      CHECK that crashes the process if V8 attempts to read a deoptimization
      literal which has been cleared. That CHECK is indeed crashing the
      process.
      
      It appears that the trouble arises in cases where the deoptimization
      data indicates that an object should be materialized as needed. In those
      cases, one of the deoptimization literals is the Map to use when
      materializing the object. It is possible to reach a part of the code
      that requires the materialized object, and therefore the Map, without
      there being any other owner of that Map. This is in contrast to most
      other deoptimization literals, which are logically equivalent to omitted
      values from the stack frame and therefore can't be reached without a
      real owner somewhere to keep them alive.
      
      To fix, I propose referring to Maps strongly from the deoptimization
      literals. The cases I investigated in v8:4578 didn't involve Maps, so I
      believe that the observed memory leaks are still fixed with this change.
      
      Bug: chromium:1268681, chromium:1268683, chromium:1268825, v8:12300
      Change-Id: Ifd32a7f9cc29e0384650013ab16e05646bf57895
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272880
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77857}
      6e9f5de2
  13. 09 Nov, 2021 1 commit
  14. 08 Nov, 2021 1 commit
  15. 18 Oct, 2021 3 commits
  16. 11 Oct, 2021 2 commits
  17. 06 Sep, 2021 1 commit
  18. 01 Sep, 2021 1 commit
  19. 25 Aug, 2021 2 commits
  20. 16 Aug, 2021 1 commit
  21. 12 Aug, 2021 1 commit
  22. 11 Aug, 2021 1 commit
  23. 20 Jul, 2021 1 commit
    • Seth Brenith's avatar
      [cleanup] Use @generateCppClass on more classes · 334b94e1
      Seth Brenith authored
      Most Torque-defined extern classes already use @generateCppClass. As
      Nico pointed out in [1], it would be nice to convert the remaining
      classes and remove this option. This change converts most of those
      remaining classes. I know that the future of Torque-defined classes is a
      subject of some debate right now, but I think that it's worth doing a
      few mechanical changes to reduce the existing variety of options.
      
      Changes that don't exactly follow the usual pattern:
      1. BigIntBase, MutableBigInt: we can define these without a body, and
         then Torque treats them as "really external" rather than "kind of
         external, but with some Torque-generated parts".
      2. RegExpMatchInfo: moved its inline functions into a separate file,
         which the generated -tq.cc file requires.
      
      [1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit#
      
      Bug: v8:8952
      Change-Id: I84c7958a295caa0bab847683c05022e18c921cad
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027742Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#75817}
      334b94e1
  24. 19 Jul, 2021 2 commits
  25. 08 Jul, 2021 1 commit
  26. 06 Jul, 2021 1 commit
    • Dominik Inführ's avatar
      [heap] Support transitioning of code objects · d1f2a83b
      Dominik Inführ authored
      This CL adds support for updating code objects. So far code objects
      were immutable. Sparkplug makes compilation a very frequent operation
      and thus wants to avoid copying the instruction stream from the
      AssemblerBuffer into the code object (with more overhead that entails).
      The idea is to allocate an "empty" Code object initially, which is
      likely large enough to hold the full instruction stream. Then Sparkplug
      will compile the given function and write the instruction stream
      directly into the code object. After compilation is done Sparkplug trims
      the Code to the right size and finishes its initialization.
      
      We use relocation_info to determine whether a Code object is fully
      initialized: undefined means that this object is filled by SparkPlug
      at the moment. If it's a proper ByteArray, this code object is assumed
      to be initialized. Turbofan still fully initializes the Code object
      immediately.
      
      Before changing the size of the code object, EnsureSweepingCompleted()
      makes sure that the code object's page is swept already. This prevents
      that the concurrent sweeper loads the new and smaller object size and
      stores that memory in the free list.
      
      NotifyCodeObjectChanged() signals the GC that the code object is now
      fully initialized and revisits that object (even if it is black already)
      to find and record outgoing references in the instruction stream.
      
      Design doc: https://docs.google.com/document/d/12LHGkRXY1H3IFMBrdxs2vhgtG9bfJTdquQUsX1oPoSE/edit?usp=sharing
      
      Bug: v8:11872
      Change-Id: Ie1b95b27842eea5ec7e9d345052585a27d6ea7f3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999087
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75582}
      d1f2a83b
  27. 28 Jun, 2021 1 commit
  28. 22 Jun, 2021 1 commit
  29. 18 Jun, 2021 1 commit