1. 28 Apr, 2022 1 commit
  2. 25 Apr, 2022 1 commit
  3. 22 Apr, 2022 1 commit
  4. 21 Apr, 2022 2 commits
  5. 23 Mar, 2022 1 commit
  6. 17 Feb, 2022 1 commit
  7. 28 Oct, 2021 1 commit
  8. 20 Sep, 2021 1 commit
  9. 24 Aug, 2021 1 commit
    • Dan Elphick's avatar
      Reland "[include] Split out v8.h" · ec06bb6c
      Dan Elphick authored
      This is a reland of d1b27019
      
      Fixes include:
      Adding missing file to bazel build
      Forward-declaring classing before friend-classing them to fix win/gcc
      Add missing v8-isolate.h include for vtune builds
      
      Original change's description:
      > [include] Split out v8.h
      >
      > This moves every single class/function out of include/v8.h into a
      > separate header in include/, which v8.h then includes so that
      > externally nothing appears to have changed.
      >
      > Every include of v8.h from inside v8 has been changed to a more
      > fine-grained include.
      >
      > Previously inline functions defined at the bottom of v8.h would call
      > private non-inline functions in the V8 class. Since that class is now
      > in v8-initialization.h and is rarely included (as that would create
      > dependency cycles), this is not possible and so those methods have been
      > moved out of the V8 class into the namespace v8::api_internal.
      >
      > None of the previous files in include/ now #include v8.h, which means
      > if embedders were relying on this transitive dependency then it will
      > give compile failures.
      >
      > v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      > that Chrome continue to compile but that change will be reverted once
      > those transitive #includes in chrome are changed to include it directly.
      >
      > Full design:
      > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      >
      > Bug: v8:11965
      > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#76424}
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit
      Bug: v8:11965
      Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76460}
      ec06bb6c
  10. 23 Aug, 2021 2 commits
    • Dan Elphick's avatar
      Revert "[include] Split out v8.h" · 44fe02ce
      Dan Elphick authored
      This reverts commit d1b27019.
      
      Reason for revert: Broke vtune build, tsan build and possibly others
      
      Original change's description:
      > [include] Split out v8.h
      >
      > This moves every single class/function out of include/v8.h into a
      > separate header in include/, which v8.h then includes so that
      > externally nothing appears to have changed.
      >
      > Every include of v8.h from inside v8 has been changed to a more
      > fine-grained include.
      >
      > Previously inline functions defined at the bottom of v8.h would call
      > private non-inline functions in the V8 class. Since that class is now
      > in v8-initialization.h and is rarely included (as that would create
      > dependency cycles), this is not possible and so those methods have been
      > moved out of the V8 class into the namespace v8::api_internal.
      >
      > None of the previous files in include/ now #include v8.h, which means
      > if embedders were relying on this transitive dependency then it will
      > give compile failures.
      >
      > v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      > that Chrome continue to compile but that change will be reverted once
      > those transitive #includes in chrome are changed to include it directly.
      >
      > Full design:
      > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      >
      > Bug: v8:11965
      > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#76424}
      
      Bug: v8:11965
      Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Owners-Override: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76428}
      44fe02ce
    • Dan Elphick's avatar
      [include] Split out v8.h · d1b27019
      Dan Elphick authored
      This moves every single class/function out of include/v8.h into a
      separate header in include/, which v8.h then includes so that
      externally nothing appears to have changed.
      
      Every include of v8.h from inside v8 has been changed to a more
      fine-grained include.
      
      Previously inline functions defined at the bottom of v8.h would call
      private non-inline functions in the V8 class. Since that class is now
      in v8-initialization.h and is rarely included (as that would create
      dependency cycles), this is not possible and so those methods have been
      moved out of the V8 class into the namespace v8::api_internal.
      
      None of the previous files in include/ now #include v8.h, which means
      if embedders were relying on this transitive dependency then it will
      give compile failures.
      
      v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      that Chrome continue to compile but that change will be reverted once
      those transitive #includes in chrome are changed to include it directly.
      
      Full design:
      https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      
      Bug: v8:11965
      Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76424}
      d1b27019
  11. 30 Nov, 2020 1 commit
  12. 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
  13. 21 Jul, 2020 1 commit
  14. 10 Mar, 2020 1 commit
  15. 03 Mar, 2020 1 commit
  16. 03 Feb, 2020 1 commit
  17. 16 Jan, 2020 1 commit
  18. 14 Jan, 2020 1 commit
  19. 05 Dec, 2019 1 commit
    • Ulan Degenbaev's avatar
      [heap] Decouple the lifetime of a TracedNode from the target object · d7160560
      Ulan Degenbaev authored
      Currently a TracedNode of a TracedReference is freed only if its target
      V8 object is unreachable. This is problematic for TracedNodes created for
      long-living (or immortal) V8 objects and leads to memory leaks.
      
      This CL adds logic for collecting unreachable TracedNodes:
      1) Each TracedNode gets a markbit. Initially the markbit is set (i.e.
         we have black allocation for TracedNodes).
      2) During marking RegisterEmbedderReference sets the markbit of the
         corresonding TracedNode.
      3) In the atomic pause of Mark-Compact when TracedNodes are iterated,
         we check the markbits and free TracedNodes with cleared markbits.
         After this processing all markbits are cleared for the next GC.
      
      Note that the new logic does not apply to TracedNode that have
      callbacks and/or destructors.
      
      Bug: chromium:1029738
      Change-Id: I38e76a8b4a84170793998988b1a7962e40874428
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948722
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65347}
      d7160560
  20. 13 Sep, 2019 1 commit
  21. 29 Aug, 2019 1 commit
  22. 23 Aug, 2019 1 commit
    • Michael Lippautz's avatar
      api,heap: Avoid reaching out to embedder memory on TracedGlobal reset · 0af80a37
      Michael Lippautz authored
      Avoid clearing the memory on the embedder-side of a TracedGlobal handle.
      
      When using destructors in TracedGlobal this is safe as long as the embedder
      reports the handle on tracing GCs. If the embedder does not report a handle it
      is assumed that the containing object is dead as well.
      
      Without using destructors the same argument holds for tracing GCs. In addition,
      embedders using the optimization of clearing references on non-tracing GCs
      are expected to clear the reference in ResetHandleInNonTracingGC.
      
      It is suggested that only expert embedders make use of (a) no destructors and
      (b) IsRootForNonTracingGC.
      
      Change-Id: Ia417c0eb0860094fcaa554e7046d38abac905714
      Bug: chromium:995684
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763539
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63362}
      0af80a37
  23. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  24. 23 May, 2019 3 commits
  25. 14 May, 2019 1 commit
  26. 04 Apr, 2019 1 commit
  27. 18 Mar, 2019 1 commit
  28. 11 Feb, 2019 1 commit
  29. 05 Feb, 2019 1 commit
  30. 29 Jan, 2019 1 commit
    • Michael Lippautz's avatar
      [api, global-handles] Add TracedGlobal · 76c93685
      Michael Lippautz authored
      TracedGlobal integrates with the use case of EmbedderHeapTracer and replaces
      regular weak Global or Persistent nodes for such cases. This allows to simplify
      the case for regular weak handles in a sense that they follow regular weak
      semantics (if the underlying object is otherwise unreachable the weak handle
      will be reset).
      
      TracedGlobal requires slightly different semantics in the sense that it can be
      required to keep them alive on Scavenge garbage collections because there's a
      transitive path that is only known when using the EmbedderHeapTracer.
      TracedGlobal accomodates that use case.
      
      TracedGlobal follows move semantics and can thus be used in regular std
      containers without wrapping data structure.
      
      The internal state uses 20% less memory and allows for only iterating those
      nodes when necessary. The design trades the virtual call when iterating
      interesting persistents in the GC prologue with calling out through the
      EmbedderHeapTracer for each node which is also a virtual call. There is one less
      iteration over the set of handles required though and the design is robust
      against recursive GCs that mutate the embedder state during the prologue
      callback.
      
      Bug: chromium:923361
      Change-Id: Idbacfbe4723cd12af9de21058a4792e51dc4df74
      Reviewed-on: https://chromium-review.googlesource.com/c/1425523
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59183}
      76c93685
  31. 24 Jan, 2019 1 commit
  32. 23 Jan, 2019 2 commits
  33. 22 Jan, 2019 3 commits