1. 09 Aug, 2021 1 commit
    • Leszek Swirski's avatar
      [api] Add API for off-thread code cache deserialization · f888f48e
      Leszek Swirski authored
      To consume a code cache off-thread
      
        1. The embedder creates a CachedData object wrapping the data blob.
        2. The embedder calls ScriptCompiler::StartConsumingCodeCache with the
           CachedData, and receives a ScriptCompiler::CodeCacheConsumeTask
           which takes ownership of the CachedData.
        3. The embedder calls ScriptCompiler::CodeCacheConsumeTask::Run
           on a different thread.
        4. Once this completes, the embedded passes the completed task as an
           optional argument into Source constructor, and calls Compile as
           before.
      
      This is roughly similar to how streaming compilation works, with the
      QoL improvement that Source owns the CodeCacheConsumeTask and therefore
      we can reuse the same Compile method and do the off-thread finalization
      behind the scenes inside Compile.
      
      On the v8::internal side, ScriptCompiler::CodeCacheConsumeTask wraps a
      v8::internal::BackgroundDeserializeTask, which has a Run and a Finish
      method. The Run creates a LocalIsolate (again, similar to
      BackgroundCompileTask), calls some helpers on CodeSerializer, and stores
      the pre-finalization result in a OffThreadDeserializeData structure.
      This stores Persistent Handles to the off-thread initialized SFI and
      a vector of Scripts needing fixing up, and it owns the PersistentHandles
      object which owns those Handles. Finally, the Finish method consumes
      this OffThreadDeserializeData structure, fixes up Scripts, moves the
      SFI Handle into the caller HandleScope, and that's it.
      
      Since we don't yet have the source at off-thread deserialization time,
      the various code cache sanity checks are done without the source hash
      when deserializing, and the Finish method re-does them now that the
      source is available.
      
      Bug: chromium:1075999
      Change-Id: If1faf35ba3ef840fa4e735581d0b29c96c1d5fc8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067322
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76155}
      f888f48e
  2. 06 Aug, 2021 1 commit
    • Leszek Swirski's avatar
      Revert "[counters] Fix reentrant timers for V8.Execute" · a12c6fa2
      Leszek Swirski authored
      This reverts commit fffcbaea.
      
      Reason for revert: Breaks in Chromium (e.g. https://ci.chromium.org/p/v8/builders/ci/Linux%20V8%20FYI%20Release%20%28NVIDIA%29)
      
      Original change's description:
      > [counters] Fix reentrant timers for V8.Execute
      >
      > This CL fixes a long standing issue where reentering TimedHistograms
      > scopes would cause spurious measurements. Only the non-nested scopes
      > yielded correct results.
      >
      > Due to the changed numbers, the V8.Execute histogram is renamed to
      > V8.ExecuteMicroSeconds. Note that this histogram is also guarded
      > behind the --slow-histograms flag due to the additional overhead.
      >
      > Unlike before, it does no longer include time for external callbacks
      > and only measures self time. The following example illustrates the
      > new behaviour:
      >
      > 1. Enter V8:           |--+.......+--| self-time: 4 units (reported)
      > 2. Exit V8 (callback):    |-+...+-|    self-time: 2 units (ignored)
      > 3. Re-enter V8:             |---|      self-time: 3 units (reported)
      >
      > This would result in 2 histogram entries with 4 time units for the first
      > V8 slice and 3 units for the nested part. Note that the callback time
      > itself is ignored.
      >
      > This CL attempts to clean up how TimedHistograms work:
      > - Histogram: the base class
      > - TimedHistograms: used for time-related histograms that are not nested
      > - NestedTimeHistograms: Extends TimedHistograms and is used for nested
      >   histograms
      >
      > This CL changes Histograms to not measure time themselves. Measurements
      > happen in the *HistogramScopes:
      > - BaseTimedHistogramScope: Base functionality
      > - TimedHistogramScope: For non-nested measurements
      > - NestedTimedHistogramScope: For nested measurements
      > - PauseNestedTimedHistogramScope: Ignore time during a given scope.
      >   This is used to pause timers during callbacks.
      >
      > Additional changes:
      > - ExternalCallbackScope now contains a PauseNestedTimedHistogramScope
      >   and always sets VMState<EXTERNAL>
      >
      > Bug: v8:11946
      > Change-Id: I45e4b7ff77b5948b605dd50539044cb26222fa21
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3001345
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Reviewed-by: Victor Gomes <victorgomes@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#76111}
      
      Bug: v8:11946
      Change-Id: I954de1afbabf101fb5d4f52eca0d3b80a723385b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3077153
      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/master@{#76138}
      a12c6fa2
  3. 05 Aug, 2021 1 commit
    • Camillo Bruni's avatar
      [counters] Fix reentrant timers for V8.Execute · fffcbaea
      Camillo Bruni authored
      This CL fixes a long standing issue where reentering TimedHistograms
      scopes would cause spurious measurements. Only the non-nested scopes
      yielded correct results.
      
      Due to the changed numbers, the V8.Execute histogram is renamed to
      V8.ExecuteMicroSeconds. Note that this histogram is also guarded
      behind the --slow-histograms flag due to the additional overhead.
      
      Unlike before, it does no longer include time for external callbacks
      and only measures self time. The following example illustrates the
      new behaviour:
      
      1. Enter V8:           |--+.......+--| self-time: 4 units (reported)
      2. Exit V8 (callback):    |-+...+-|    self-time: 2 units (ignored)
      3. Re-enter V8:             |---|      self-time: 3 units (reported)
      
      This would result in 2 histogram entries with 4 time units for the first
      V8 slice and 3 units for the nested part. Note that the callback time
      itself is ignored.
      
      This CL attempts to clean up how TimedHistograms work:
      - Histogram: the base class
      - TimedHistograms: used for time-related histograms that are not nested
      - NestedTimeHistograms: Extends TimedHistograms and is used for nested
        histograms
      
      This CL changes Histograms to not measure time themselves. Measurements
      happen in the *HistogramScopes:
      - BaseTimedHistogramScope: Base functionality
      - TimedHistogramScope: For non-nested measurements
      - NestedTimedHistogramScope: For nested measurements
      - PauseNestedTimedHistogramScope: Ignore time during a given scope.
        This is used to pause timers during callbacks.
      
      Additional changes:
      - ExternalCallbackScope now contains a PauseNestedTimedHistogramScope
        and always sets VMState<EXTERNAL>
      
      Bug: v8:11946
      Change-Id: I45e4b7ff77b5948b605dd50539044cb26222fa21
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3001345Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76111}
      fffcbaea
  4. 27 Jul, 2021 1 commit
  5. 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
  6. 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
  7. 20 Jul, 2021 2 commits
    • Igor Sheludko's avatar
      [ext-code-space][heap] Implement custom marking of CodeObjectSlots · 69b1e0ec
      Igor Sheludko authored
      ... which will update both the CodeObjectSlot contents and the cached
      value of the code entry point when the pointed Code object is
      evacuated.
      This is done by introducing an OLD_TO_CODE remembered set which is
      populated with the recorded slots containing pointers to Code objects.
      CodeDataContainer is the only kind of holder that can contain Code
      pointers, so having a CodeObjectSlot is enough to compute the holder
      CodeDataContainer object and update the cached code entry point there.
      
      This CL fixes the data race in the previous implementation which were
      updating the code entry point during Code object migration.
      
      Bug: v8:11880
      Change-Id: I44aa46af4bad7eb4eaa922b6876d5f2f836e0791
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035084
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75826}
      69b1e0ec
    • 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
  8. 19 Jul, 2021 1 commit
  9. 12 Jul, 2021 3 commits
    • Peter Kasting's avatar
      Fix some instances of -Wunreachable-code-aggressive. · ca596361
      Peter Kasting authored
      These need some consideration.  Clang apparently considers V8_UNLIKELY
      to mean "always false", which seems questionable to me (possibly a
      bug?).  That said, removing it in the cases here doesn't seem likely to
      cause problems -- the logging instance seems fine, and the other used to
      not have the macro and gained it in a commit that seemed to have nothing
      to do with performance.
      
      The trampoline register change is safe, but perhaps V8 will support an
      architecture in the future which needs this conditional?
      
      I'd leave these as-is, but it also seems a shame not to enable
      -Wunreachable-code-aggressive just because of these...
      
      Bug: chromium:1066980
      Change-Id: Ib819298cecba082666c26fa7010009f8e9441bf8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2994805
      Auto-Submit: Peter Kasting <pkasting@chromium.org>
      Commit-Queue: Hannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75681}
      ca596361
    • 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
  10. 05 Jul, 2021 2 commits
  11. 29 Jun, 2021 1 commit
  12. 23 Jun, 2021 1 commit
  13. 22 Jun, 2021 2 commits
  14. 18 Jun, 2021 1 commit
  15. 17 Jun, 2021 3 commits
  16. 16 Jun, 2021 3 commits
  17. 15 Jun, 2021 1 commit
  18. 14 Jun, 2021 2 commits
  19. 10 Jun, 2021 2 commits
  20. 09 Jun, 2021 2 commits
  21. 07 Jun, 2021 2 commits
  22. 19 May, 2021 1 commit
  23. 14 May, 2021 1 commit
  24. 10 May, 2021 3 commits