Skip to content

V
V8
Switch branch/tag
  1. 24 Feb, 2022 1 commit
  3. 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
  5. 21 Feb, 2022 2 commits
  7. 10 Feb, 2022 1 commit
  9. 07 Feb, 2022 1 commit
  11. 31 Jan, 2022 1 commit
  13. 20 Jan, 2022 1 commit
  15. 16 Dec, 2021 1 commit
  17. 14 Dec, 2021 4 commits
  19. 30 Nov, 2021 2 commits
  21. 18 Nov, 2021 2 commits
  23. 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
  25. 09 Nov, 2021 1 commit
  27. 08 Nov, 2021 1 commit
  29. 18 Oct, 2021 3 commits
  31. 11 Oct, 2021 2 commits
  33. 06 Sep, 2021 1 commit
  35. 01 Sep, 2021 1 commit
  37. 25 Aug, 2021 2 commits
  39. 16 Aug, 2021 1 commit
  41. 12 Aug, 2021 1 commit
  43. 11 Aug, 2021 1 commit
  45. 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
  47. 19 Jul, 2021 2 commits
  49. 08 Jul, 2021 1 commit
  51. 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
  53. 28 Jun, 2021 1 commit
  55. 22 Jun, 2021 1 commit
  57. 18 Jun, 2021 1 commit