1. 30 Aug, 2021 1 commit
  2. 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
  3. 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
  4. 30 Jul, 2021 1 commit
  5. 29 Jul, 2021 1 commit
    • Mythri A's avatar
      [sparkplug] Introduce flush_baseline_code flag · 64556d13
      Mythri A authored
      Introduce a flush_baseline_code flag to control if baseline code is
      flushed or not. Currently flush_baseline_code implies flush_bytecode
      as well. So if flush_baseline_code is enabled both bytecode and baseline
      code are flushed. If the flag is disabled we only flush bytecode and
      not baseline code.
      
      In a follow-up CL we will add support to control baseline and bytecode
      flushing independently i.e. we can flush only bytecode / only baseline
      code / both.
      
      Bug: v8:11947
      Change-Id: I5a90ed38469de64ed1d736d1eaaeabc2985f0783
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059684
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76003}
      64556d13
  6. 26 Jul, 2021 1 commit
    • Leszek Swirski's avatar
      Reland "[offthread] Template deserializer on Isolate" · 6f898234
      Leszek Swirski authored
      This is a reland of e24fa913
      It fixes the heap verification errors by going back to using MakeThin
      instead of manually creating a filler (that then makes the verifier
      think that this was array left-trimming).
      
      Original change's description:
      > [offthread] Template deserializer on Isolate
      >
      > Make the deserializer class templated on Isolate/LocalIsolate. This
      > allows the ObjectSerializer to be split into a main-thread and offthread
      > variant, with the latter taking a LocalIsolate.
      >
      > Eventually, we probably want to anyway split off the code-cache de/serializer
      > to a separate implementation (for various reasons), and this the only one that
      > wants off-thread finalization, and at this point the deserializer can revert
      > back to being un-templated, used only for bootstrapping. However, this is the
      > simplest way, for now, to enable off-thread deserialization.
      >
      > Bug: chromium:1075999
      > Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75834}
      
      Bug: chromium:1075999
      Change-Id: I1d81fad2550a2a9f04dd0f9d8e66422d28faf378
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043960Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75918}
      6f898234
  7. 23 Jul, 2021 1 commit
    • Michael Lippautz's avatar
      Reland "Reland "heap: Fix initial GC configuration for C++-only heaps"" · b125c943
      Michael Lippautz authored
      This is a reland of 1f0b0ed0
      
      No actual code has changed in the relands.
      
      The change was reverted due to triggering flaky failures in
      WebMediaPlayerImplTest which was not set up properly. The test setup
      has been fixed in https://crrev.com/c/3025796.
      
      Original change's description:
      > Reland "heap: Fix initial GC configuration for C++-only heaps"
      >
      > This is a reland of 7ef67b2e
      >
      > Manually checked that the CL was not the culprit breaking
      >   media_blink_unittests --gtest_filter=WebMediaPlayerImplTest.MemDumpReporting
      >
      > Original change's description:
      > > heap: Fix initial GC configuration for C++-only heaps
      > >
      > > Heaps in V8 start with a large limit that is shrunk upon young
      > > generation GCs, based on some liveness estimate. This provides best
      > > throughput during startup while at the same time finding a reasonable
      > > first limit.
      > >
      > > For C++ (embedder memory) there is no estimate which is why it was
      > > piggy-backing on V8. This breaks in scenarios where no JS memory is
      > > allocated.
      > >
      > > In this fix we start a memory reducer after embedder memory has hit
      > > the activation threshold if no GC happened so far. As soon as a single
      > > Scavenger has happened, we leave it up to the JS estimate to figure
      > > out a limit. Memory reducing GCs will then find a regular limit based
      > > on the initial live size.
      > >
      > > Drive-by: Give embedders the same activiation threshold of 8MB as JS.
      > >
      > > Bug: chromium:1217076
      > > Change-Id: I8469696002ac2af8d75d6b47def062d2608387a1
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944935
      > > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#75012}
      >
      > Bug: chromium:1217076
      > Change-Id: I482d8525379e33095834d5b41be8bb49bdd8a5d4
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2949094
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75048}
      
      Bug: chromium:1217076
      Change-Id: If920d6b2c54a0c9d67e55e276421e4694eb1414e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960218Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75894}
      b125c943
  8. 21 Jul, 2021 2 commits
    • Nico Hartmann's avatar
      Revert "[offthread] Template deserializer on Isolate" · c73d759b
      Nico Hartmann authored
      This reverts commit e24fa913.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/18917/overview
      
      Original change's description:
      > [offthread] Template deserializer on Isolate
      >
      > Make the deserializer class templated on Isolate/LocalIsolate. This
      > allows the ObjectSerializer to be split into a main-thread and offthread
      > variant, with the latter taking a LocalIsolate.
      >
      > Eventually, we probably want to anyway split off the code-cache de/serializer
      > to a separate implementation (for various reasons), and this the only one that
      > wants off-thread finalization, and at this point the deserializer can revert
      > back to being un-templated, used only for bootstrapping. However, this is the
      > simplest way, for now, to enable off-thread deserialization.
      >
      > Bug: chromium:1075999
      > Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75834}
      
      Bug: chromium:1075999
      Change-Id: Id699ebe0c17d3a61ec35b0f78417306175271647
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041675Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75836}
      c73d759b
    • Leszek Swirski's avatar
      [offthread] Template deserializer on Isolate · e24fa913
      Leszek Swirski authored
      Make the deserializer class templated on Isolate/LocalIsolate. This
      allows the ObjectSerializer to be split into a main-thread and offthread
      variant, with the latter taking a LocalIsolate.
      
      Eventually, we probably want to anyway split off the code-cache de/serializer
      to a separate implementation (for various reasons), and this the only one that
      wants off-thread finalization, and at this point the deserializer can revert
      back to being un-templated, used only for bootstrapping. However, this is the
      simplest way, for now, to enable off-thread deserialization.
      
      Bug: chromium:1075999
      Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75834}
      e24fa913
  9. 20 Jul, 2021 1 commit
    • Mythri A's avatar
      Reland "[sparkplug] Support bytecode / baseline code flushing with sparkplug" · 3ae733f9
      Mythri A authored
      This is a reland of ea55438a. Relanding
      after a fix lands here:
      https://chromium-review.googlesource.com/c/v8/v8/+/3030711. The failures
      were caused because baseline code could be flushed during the process
      of deoptimization after we choose which entry (InterpreterEnterAt* /
      BaselineEnterAt* ) builtin to use. BaselineEnterAt* builtins expect
      baseline code but it could be flushed before we execute the builtin. The
      fix is to defer the decision.
      
      Original change's description:
      > [sparkplug] Support bytecode / baseline code flushing with sparkplug
      >
      > Currently with sparkplug we don't flush bytecode / baseline code of
      > functions that were tiered up to sparkplug. This CL adds the support to
      > flush baseline code / bytecode of functions that have baseline code too.
      > This CL:
      > 1. Updates the BodyDescriptor of JSFunction to treat the Code field of
      > JSFunction as a custom weak pointer where the code is treated as weak if
      > the bytecode corresponding to this function is old.
      > 2. Updates GC to handle the functions that had a weak code object during
      > the atomic phase of GC.
      > 3. Updates the check for old bytecode to also consider when there is
      > baseline code on the function.
      >
      > This CL doesn't change any heuristics for flushing. The baseline code
      > will be flushed at the same time as bytecode.
      >
      > Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
      > Bug: v8:11947
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
      > Commit-Queue: Mythri Alle <mythria@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75674}
      
      Bug: v8:11947
      Change-Id: I63dce4cd9f6271c54049cc09f95d12e2795f15d1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035774Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75810}
      3ae733f9
  10. 19 Jul, 2021 1 commit
  11. 15 Jul, 2021 1 commit
  12. 12 Jul, 2021 2 commits
    • Mythri Alle's avatar
      Revert "[sparkplug] Support bytecode / baseline code flushing with sparkplug" · a079f057
      Mythri Alle authored
      This reverts commit ea55438a.
      
      Reason for revert: Likely culprit for these failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20NumFuzz/15494/overview
      
      Original change's description:
      > [sparkplug] Support bytecode / baseline code flushing with sparkplug
      >
      > Currently with sparkplug we don't flush bytecode / baseline code of
      > functions that were tiered up to sparkplug. This CL adds the support to
      > flush baseline code / bytecode of functions that have baseline code too.
      > This CL:
      > 1. Updates the BodyDescriptor of JSFunction to treat the Code field of
      > JSFunction as a custom weak pointer where the code is treated as weak if
      > the bytecode corresponding to this function is old.
      > 2. Updates GC to handle the functions that had a weak code object during
      > the atomic phase of GC.
      > 3. Updates the check for old bytecode to also consider when there is
      > baseline code on the function.
      >
      > This CL doesn't change any heuristics for flushing. The baseline code
      > will be flushed at the same time as bytecode.
      >
      > Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
      > Bug: v8:11947
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
      > Commit-Queue: Mythri Alle <mythria@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75674}
      
      Bug: v8:11947
      Change-Id: I50535b9a6c6fc39eceb4f6c0e0c84c55bb92f30a
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017811Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75679}
      a079f057
    • Mythri A's avatar
      [sparkplug] Support bytecode / baseline code flushing with sparkplug · ea55438a
      Mythri A authored
      Currently with sparkplug we don't flush bytecode / baseline code of
      functions that were tiered up to sparkplug. This CL adds the support to
      flush baseline code / bytecode of functions that have baseline code too.
      This CL:
      1. Updates the BodyDescriptor of JSFunction to treat the Code field of
      JSFunction as a custom weak pointer where the code is treated as weak if
      the bytecode corresponding to this function is old.
      2. Updates GC to handle the functions that had a weak code object during
      the atomic phase of GC.
      3. Updates the check for old bytecode to also consider when there is
      baseline code on the function.
      
      This CL doesn't change any heuristics for flushing. The baseline code
      will be flushed at the same time as bytecode.
      
      Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
      Bug: v8:11947
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75674}
      ea55438a
  13. 07 Jul, 2021 1 commit
  14. 06 Jul, 2021 2 commits
    • 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
    • Wenyu Zhao's avatar
      [heap] Allow TPH to access some heap private interfaces. · c25a324d
      Wenyu Zhao authored
      This CL make TPH be able to access some heap private interfaces, by
      marking TPH classes as friend classes.
      
      Bug: v8:11641
      Change-Id: I72aebf267c8f36593f50279bec5dccb44cda9528
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2994220
      Auto-Submit: Wenyu Zhao <wenyu.zhao@anu.edu.au>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Wenyu Zhao <wenyu.zhao@anu.edu.au>
      Cr-Commit-Position: refs/heads/master@{#75572}
      c25a324d
  15. 30 Jun, 2021 2 commits
    • Victor Gomes's avatar
      [heap] Adds UndoLastAllocationAt · 444fdfde
      Victor Gomes authored
      If the object to be trimmed creates a filler object that is located just
      before the current LAB, then we can immediately give back the memory.
      
      Bug: v8:11872, v8:11883
      Change-Id: I9ec37443482334003b3752a3f25fc5dcb6a476fc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2996643Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75475}
      444fdfde
    • Jakob Gruber's avatar
      [compiler] Concurrent JSGlobalObjectRef::GetPropertyCell · 76b9d98f
      Jakob Gruber authored
      .. and make JSGlobalObjectRef bg-serialized.
      
      GetPropertyCell was implemented as:
      
       LookupIterator it(holder, isolate, name, LookupIterator::OWN);
       it.TryLookupCachedProperty();
       if (it.state() == LookupIterator::DATA) it.GetPropertyCell();
      
      Due to concurrency requirements, we essentially have to reimplement
      this entire path for use in a concurrent setting:
      
       - Reads in some cases have to use relaxed or acquire semantics.
       - The IsPendingAllocation predicate must be called on some objects
         before reading into them.
       - Repeated reads of the same field must be avoided due to the
         possibility of concurrent modifications.
      
      This CL introduces two new methods:
      
      ConcurrentLookupIterator::TryGetPropertyCell implements the outer
      lookup logic, including the repeated lookup for accessors / cached
      property names.
      
      GlobalDictionary::TryFindPropertyCellForConcurrentLookupIterator is a
      slightly modified HashTable::FindEntry which follows the above rules.
      
      Bug: v8:7790
      Change-Id: Ic9a52da766afdfedce8efcbda92876845a17eed9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2959616Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75467}
      76b9d98f
  16. 21 Jun, 2021 1 commit
  17. 17 Jun, 2021 1 commit
  18. 16 Jun, 2021 2 commits
  19. 14 Jun, 2021 1 commit
  20. 10 Jun, 2021 2 commits
    • Sathya Gunasekaran's avatar
      Revert "Reland "heap: Fix initial GC configuration for C++-only heaps"" · e3d280ce
      Sathya Gunasekaran authored
      This reverts commit 1f0b0ed0.
      
      Reason for revert: still crashing https://ci.chromium.org/ui/p/chromium/builders/try/android-marshmallow-arm64-rel/877258/test-results
      
      Original change's description:
      > Reland "heap: Fix initial GC configuration for C++-only heaps"
      >
      > This is a reland of 7ef67b2e
      >
      > Manually checked that the CL was not the culprit breaking
      >   media_blink_unittests --gtest_filter=WebMediaPlayerImplTest.MemDumpReporting
      >
      > Original change's description:
      > > heap: Fix initial GC configuration for C++-only heaps
      > >
      > > Heaps in V8 start with a large limit that is shrunk upon young
      > > generation GCs, based on some liveness estimate. This provides best
      > > throughput during startup while at the same time finding a reasonable
      > > first limit.
      > >
      > > For C++ (embedder memory) there is no estimate which is why it was
      > > piggy-backing on V8. This breaks in scenarios where no JS memory is
      > > allocated.
      > >
      > > In this fix we start a memory reducer after embedder memory has hit
      > > the activation threshold if no GC happened so far. As soon as a single
      > > Scavenger has happened, we leave it up to the JS estimate to figure
      > > out a limit. Memory reducing GCs will then find a regular limit based
      > > on the initial live size.
      > >
      > > Drive-by: Give embedders the same activiation threshold of 8MB as JS.
      > >
      > > Bug: chromium:1217076
      > > Change-Id: I8469696002ac2af8d75d6b47def062d2608387a1
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944935
      > > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#75012}
      >
      > Bug: chromium:1217076
      > Change-Id: I482d8525379e33095834d5b41be8bb49bdd8a5d4
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2949094
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75048}
      
      Bug: chromium:1217076
      Change-Id: Ia409d7a3a22127af749cff5eb5db1ff508b969e4
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2951468
      Auto-Submit: Sathya Gunasekaran  <gsathya@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/master@{#75068}
      e3d280ce
    • Daoming Qiu's avatar
      This patch enables huge page support for V8's default platform. · e8fe5293
      Daoming Qiu authored
      It adjusts V8 page size for performance reasons.
      The main use case is improving Node.js performance.
      The design doc is at:https://docs.google.com/document/d/1CO8Q0YZKJ3QKFRTk-aoJzmSFsuI8ALYQLtsjqLzyi-0/edit?usp=sharing
      
      Change-Id: Ie037d405a7116ccd986131d22d417b86ccf6a899
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2860840Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
      Cr-Commit-Position: refs/heads/master@{#75063}
      e8fe5293
  21. 09 Jun, 2021 3 commits
    • Dominik Inführ's avatar
      [heap] Optimize Heap::IsPendingAllocation · 9140d001
      Dominik Inführ authored
      IsPendingAllocation will now load the space from the object's page
      header first and then only check the object against the current LAB
      of that particular space. Previously we were looking up that object
      in the LABs of all spaces.
      
      This new design also makes it feasible to have one dedicated mutex for
      original_top/original_limit (respectively pending_object) for each
      space. This will reduce contention on the mutexes.
      
      Change-Id: I8e7636410259fd03b7970084bfbbaeadb2d8ba61
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2936606
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75054}
      9140d001
    • Michael Lippautz's avatar
      Reland "heap: Fix initial GC configuration for C++-only heaps" · 1f0b0ed0
      Michael Lippautz authored
      This is a reland of 7ef67b2e
      
      Manually checked that the CL was not the culprit breaking
        media_blink_unittests --gtest_filter=WebMediaPlayerImplTest.MemDumpReporting
      
      Original change's description:
      > heap: Fix initial GC configuration for C++-only heaps
      >
      > Heaps in V8 start with a large limit that is shrunk upon young
      > generation GCs, based on some liveness estimate. This provides best
      > throughput during startup while at the same time finding a reasonable
      > first limit.
      >
      > For C++ (embedder memory) there is no estimate which is why it was
      > piggy-backing on V8. This breaks in scenarios where no JS memory is
      > allocated.
      >
      > In this fix we start a memory reducer after embedder memory has hit
      > the activation threshold if no GC happened so far. As soon as a single
      > Scavenger has happened, we leave it up to the JS estimate to figure
      > out a limit. Memory reducing GCs will then find a regular limit based
      > on the initial live size.
      >
      > Drive-by: Give embedders the same activiation threshold of 8MB as JS.
      >
      > Bug: chromium:1217076
      > Change-Id: I8469696002ac2af8d75d6b47def062d2608387a1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944935
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75012}
      
      Bug: chromium:1217076
      Change-Id: I482d8525379e33095834d5b41be8bb49bdd8a5d4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2949094
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75048}
      1f0b0ed0
    • Maya Lekova's avatar
      Revert "heap: Fix initial GC configuration for C++-only heaps" · 4acc0358
      Maya Lekova authored
      This reverts commit 7ef67b2e.
      
      Reason for revert: Speculative revert for a blocked roll - https://chromium-review.googlesource.com/c/chromium/src/+/2947365
      
      Original change's description:
      > heap: Fix initial GC configuration for C++-only heaps
      >
      > Heaps in V8 start with a large limit that is shrunk upon young
      > generation GCs, based on some liveness estimate. This provides best
      > throughput during startup while at the same time finding a reasonable
      > first limit.
      >
      > For C++ (embedder memory) there is no estimate which is why it was
      > piggy-backing on V8. This breaks in scenarios where no JS memory is
      > allocated.
      >
      > In this fix we start a memory reducer after embedder memory has hit
      > the activation threshold if no GC happened so far. As soon as a single
      > Scavenger has happened, we leave it up to the JS estimate to figure
      > out a limit. Memory reducing GCs will then find a regular limit based
      > on the initial live size.
      >
      > Drive-by: Give embedders the same activiation threshold of 8MB as JS.
      >
      > Bug: chromium:1217076
      > Change-Id: I8469696002ac2af8d75d6b47def062d2608387a1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944935
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75012}
      
      Bug: chromium:1217076
      Change-Id: Ic1530162e846c2a767ea5ea902a01a21967d8e35
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2947419
      Auto-Submit: Maya Lekova <mslekova@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/master@{#75034}
      4acc0358
  22. 08 Jun, 2021 1 commit
    • Michael Lippautz's avatar
      heap: Fix initial GC configuration for C++-only heaps · 7ef67b2e
      Michael Lippautz authored
      Heaps in V8 start with a large limit that is shrunk upon young
      generation GCs, based on some liveness estimate. This provides best
      throughput during startup while at the same time finding a reasonable
      first limit.
      
      For C++ (embedder memory) there is no estimate which is why it was
      piggy-backing on V8. This breaks in scenarios where no JS memory is
      allocated.
      
      In this fix we start a memory reducer after embedder memory has hit
      the activation threshold if no GC happened so far. As soon as a single
      Scavenger has happened, we leave it up to the JS estimate to figure
      out a limit. Memory reducing GCs will then find a regular limit based
      on the initial live size.
      
      Drive-by: Give embedders the same activiation threshold of 8MB as JS.
      
      Bug: chromium:1217076
      Change-Id: I8469696002ac2af8d75d6b47def062d2608387a1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944935Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75012}
      7ef67b2e
  23. 07 Jun, 2021 2 commits
  24. 02 Jun, 2021 1 commit
  25. 31 May, 2021 1 commit
  26. 27 May, 2021 3 commits
  27. 17 May, 2021 1 commit
  28. 14 May, 2021 1 commit
    • Shu-yu Guo's avatar
      Reland^4 "[ptr-cage] Turn on shared pointer cage by default for arm64 and x64" · baa4ba3f
      Shu-yu Guo authored
      This is a reland of 8b74fd45
      
      Changes since revert:
      
      - Reverted a61aa491 for not fixing the
        jitless toggling issue on Chromium Win64
      
      - Fix jitless toggling on Win64 by checking FLAG_jitless in
        EmbeddedDataWithMaybeRemappedEmbeddedBuiltins
      
      Original change's description:
      > Reland^3 "[ptr-cage] Turn on shared pointer cage by default for arm64 and x64""
      >
      > This is a reland of 054ff044
      >
      > Change since revert:
      >
      > - Remove assignment to FLAG_enable_short_builtins in test since
      >   it's write-once in CFI.
      >
      > Original change's description:
      > > Reland^2 "[ptr-cage] Turn on shared pointer cage by default for arm64 and x64"
      > >
      > > This is a reland of 1f504c36
      > >
      > > Changes since revert:
      > >
      > > - Removed disabling of RO heap sharing when --stress-snapshot is passed;
      > >   was fixed by f4a6c628
      > > - Fixed crashing tests that caused revert separately in
      > >   a61aa491
      > >
      > > Original change's description:
      > > > > [ptr-cage] Turn on shared pointer cage by default for arm64 and x64
      > > > >
      > > > > Reviewed-on:
      > > > https://chromium-review.googlesource.com/c/v8/v8/+/2873226
      > > > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > > > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > > > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > > > > Cr-Commit-Position: refs/heads/master@{#74422}
      > > >
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878855
      > > > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > > > Reviewed-by: Adam Klein <adamk@chromium.org>
      > > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > > Reviewed-by: Dan Elphick <delphick@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#74448}
      > >
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891460
      > > Reviewed-by: Adam Klein <adamk@chromium.org>
      > > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#74546}
      >
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2893567
      > Reviewed-by: Shu-yu Guo <syg@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#74548}
      
      TBR=ishell@chromium.org
      
      Bug: v8:11460
      Change-Id: Ied925de5f886a906b1ca178365aee73155e679cb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891697Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74560}
      baa4ba3f