1. 13 May, 2022 1 commit
  2. 04 Apr, 2022 2 commits
    • Jakob Gruber's avatar
      [osr] Fall back to synchronous OSR on cache mismatches · 3f5a3df6
      Jakob Gruber authored
      If we've already cached OSR'd code for the current function but with a
      different osr offset, fall back to synchronous compilation. This avoids
      degenerate cases where we repeatedly spawn OSR jobs but then fail to
      install them.
      
      Drive-by: More consistent --trace-osr output.
      Drive-by: Rename kCompileForOnStackReplacement to kCompileOptimizeOSR
      for name consistency.
      Drive-by: Add JSFunction::DebugNameCStr() for more convenient PrintF's.
      
      Bug: v8:12161
      Change-Id: I2b4a65bc9e082d85d7048a3e92ef86b07d396687
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560431Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79761}
      3f5a3df6
    • Jakob Gruber's avatar
      Reland "[osr] Basic support for concurrent OSR" · d187c6c2
      Jakob Gruber authored
      This is a reland of commit 3ce690ee
      
      Changed for the reland:
      - Remove the currently-unused BytecodeArray member to avoid MSAN
        failures.
      - s/return/continue/ in optimizing-compile-dispatcher.
      
      Original change's description:
      > [osr] Basic support for concurrent OSR
      >
      > This CL adds basic support behind --concurrent-osr,
      > disabled by default.
      >
      > When enabled:
      > 1) the first OSR request starts a concurrent OSR compile job.
      > 2) on completion, the code object is inserted into the OSR cache.
      > 3) the next OSR request picks up the cached code (assuming the request
      >    came from the same JumpLoop bytecode).
      >
      > We add a new osr optimization marker on the feedback vector to
      > track whether an OSR compile is currently in progress.
      >
      > One fundamental issue remains: step 3) above is not guaranteed to
      > hit the same JumpLoop, and a mismatch means the OSR'd code cannot
      > be installed. This will be addressed in a followup by targeting
      > specific bytecode offsets for the install request.
      >
      > This change is based on fanchen.kong@intel.com's earlier
      > change crrev.com/c/3369361, thank you!
      >
      > Bug: v8:12161
      > Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79685}
      
      Bug: v8:12161
      Change-Id: I48b100e5980c909ec5e79d190aaea730c83e9386
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565720Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Auto-Submit: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79746}
      d187c6c2
  3. 01 Apr, 2022 1 commit
    • Adam Klein's avatar
      Revert "[osr] Basic support for concurrent OSR" · 32f28553
      Adam Klein authored
      This reverts commit 3ce690ee.
      
      Reason for revert: failures on CrOS MSan build: https://crbug.com/1312188
      
      Original change's description:
      > [osr] Basic support for concurrent OSR
      >
      > This CL adds basic support behind --concurrent-osr,
      > disabled by default.
      >
      > When enabled:
      > 1) the first OSR request starts a concurrent OSR compile job.
      > 2) on completion, the code object is inserted into the OSR cache.
      > 3) the next OSR request picks up the cached code (assuming the request
      >    came from the same JumpLoop bytecode).
      >
      > We add a new osr optimization marker on the feedback vector to
      > track whether an OSR compile is currently in progress.
      >
      > One fundamental issue remains: step 3) above is not guaranteed to
      > hit the same JumpLoop, and a mismatch means the OSR'd code cannot
      > be installed. This will be addressed in a followup by targeting
      > specific bytecode offsets for the install request.
      >
      > This change is based on fanchen.kong@intel.com's earlier
      > change crrev.com/c/3369361, thank you!
      >
      > Bug: v8:12161
      > Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79685}
      
      Bug: v8:12161, chromium:1312188
      Change-Id: Iac1e3fd67ecc658a1cdee8f4d13354c097ed6697
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3564983
      Auto-Submit: Adam Klein <adamk@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79702}
      32f28553
  4. 31 Mar, 2022 1 commit
    • Jakob Gruber's avatar
      [osr] Basic support for concurrent OSR · 3ce690ee
      Jakob Gruber authored
      This CL adds basic support behind --concurrent-osr,
      disabled by default.
      
      When enabled:
      1) the first OSR request starts a concurrent OSR compile job.
      2) on completion, the code object is inserted into the OSR cache.
      3) the next OSR request picks up the cached code (assuming the request
         came from the same JumpLoop bytecode).
      
      We add a new osr optimization marker on the feedback vector to
      track whether an OSR compile is currently in progress.
      
      One fundamental issue remains: step 3) above is not guaranteed to
      hit the same JumpLoop, and a mismatch means the OSR'd code cannot
      be installed. This will be addressed in a followup by targeting
      specific bytecode offsets for the install request.
      
      This change is based on fanchen.kong@intel.com's earlier
      change crrev.com/c/3369361, thank you!
      
      Bug: v8:12161
      Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79685}
      3ce690ee
  5. 30 Mar, 2022 1 commit
    • Jakob Gruber's avatar
      Refactor OptimizationMarker and ConcurrencyMode enums · 57d985a5
      Jakob Gruber authored
      .. with readability and simplicity in mind.
      
      - Rename OptimizationMarker to the (shorter) TieringState. 'Tiering'
        also matches 'TieringManager' terminology.
      - Rename the values:
        kNone -> kNone
        kInOptimizationQueue -> kInProgress
        kCompileFoo_NotConcurrent -> kRequestFoo_Synchronous
        kCompileFoo_Concurrent -> kRequestFoo_Concurrent
      - Likewise rename ConcurrencyMode::kNotConcurrent to kSynchronous.
      - Add predicates to test enum values.
      - Consistent lower case names for accessors on JSFunction and
        FeedbackVector.
      - Instead of having to call HasOptimizationMarker() before using any
        other accessor, simply have optimization_marker() return kNone if
        no feedback vector exists.
      - Drive-by: Enable the Unreachable() in MaybeOptimizeCode()
        unconditionally - this should never happen, there's no reason not
        to protect against this in release builds as well.
      
      Bug: v8:12161
      Change-Id: I67c03e2b7bd0a6b86d0c64f504ad8cb47e9e26ae
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3555774Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Auto-Submit: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79669}
      57d985a5
  6. 25 Mar, 2022 1 commit
  7. 02 Mar, 2022 2 commits
    • Jakob Gruber's avatar
      [maglev] Basic tiering to Maglev · 123c38a5
      Jakob Gruber authored
      When --maglev is set, tier up to Maglev from unoptimized tiers based on
      --interrupt-budget-for-maglev, initially set to 40KB (which should very
      roughly by 1/10th of the time until the TF tierup decision is made).
      On the first interrupt, a non-concurrent optimization to Maglev is
      requested, which the next call to the marked function will perform.
      
      - There is no support for tiering from Maglev to TF yet.
      - Maglev's language support is minimal and tests are not expected to
        pass with --maglev.
      - Disable --maglev by default for now.
      
      Drive-by: fixes related to Maglev flag definitions.
      
      Bug: v8:7700
      Change-Id: I121bb3f4f3830fdd20e1d4a12d3e04f08a99be38
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3500302Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79328}
      123c38a5
    • Jakob Gruber's avatar
      [tiering] Centralize interrupt budget decisions · 5cdac4b8
      Jakob Gruber authored
      .. by moving them all to TieringManager.
      
      Bug: v8:7700
      Change-Id: I03eb2d1607b06ece84a1ca98ebc723788dbc0cde
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3500220
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79325}
      5cdac4b8
  8. 01 Mar, 2022 1 commit
    • Jakob Gruber's avatar
      Refactor tiering-related JSFunction methods · aad3e727
      Jakob Gruber authored
      - Add the Isolate as an explicit param (we already have it at all
        callsites)
      - Pass an explicit CodeKind param to MarkForOptimization in preparation
        for Maglev.
      - Split EnsureFeedbackVector into that, plus
        CreateAndAttachFeedbackVector for when we know it has to be created.
      
      Bug: v8:7700
      Change-Id: Ie9022deccd31d472d6df3d442b25583af5569ab0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497383
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79318}
      aad3e727
  9. 25 Feb, 2022 1 commit
  10. 24 Feb, 2022 1 commit
  11. 20 Jan, 2022 1 commit
  12. 14 Dec, 2021 1 commit
  13. 08 Nov, 2021 1 commit
  14. 07 Oct, 2021 1 commit
  15. 29 Sep, 2021 1 commit
  16. 30 Aug, 2021 1 commit
  17. 24 Aug, 2021 1 commit
  18. 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
  19. 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
  20. 19 Jul, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Make JSFunction bg-serialized · 0dba97f8
      Jakob Gruber authored
      This wraps up the transition away from kSerialized ref kinds.
      
      Since JSFunctionRef is a complex type, we don't attempt full
      consistency on the background thread. Instead, we serialize functions
      on the background in a partially-racy manner, in which consistency
      between different JSFunction fields is *not* guaranteed. Consistency
      is later verified through a new compilation dependency kind during
      finalization.
      
      Bug: v8:7790, v8:12004
      Change-Id: Ic2b78af9c9fe183c8769d323132bb304b151dc75
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968404
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75789}
      0dba97f8
  21. 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
  22. 22 Jun, 2021 1 commit
  23. 17 Jun, 2021 1 commit
  24. 15 Jun, 2021 1 commit
  25. 07 Jun, 2021 1 commit
  26. 10 May, 2021 1 commit
  27. 04 May, 2021 1 commit
  28. 26 Apr, 2021 1 commit
  29. 15 Apr, 2021 1 commit
  30. 31 Mar, 2021 1 commit
  31. 17 Mar, 2021 2 commits
  32. 23 Feb, 2021 1 commit
  33. 22 Feb, 2021 1 commit
    • Mythri A's avatar
      [turboprop] Reduce BytecodeBudgetInterrupt overhead from Turboprop · 5b783479
      Mythri A authored
      Earlier we used the same interrupt budget always and waited for higher
      number of ticks when tiering up from Turboprop to TurboFan. On some of
      the real world pages this adds a reasonable overhead for processing
      these interrupts. This cl sets the interrupt budget to a higher value so
      there are fewer interrupts. This cl:
      1. Sets the interrupt budget on feedback cell to
      FLAG_interrupt_budget * scale factor when we install optimized code.
      2. Resets the budget to FLAG_interrupt_budget when there is a
      deoptimization.
      3. Updates the runtime profiler to remove the scaling of number of ticks
      needed for optimization when tiering up from TP to TF.
      
      On sheets benchmark, we spend 40-50ms when servicing interrupts from
      Turboprop code. This change brings it down to ~7ms. We also see
      improvements on other pages.
      
      
      Bug: v8:9684
      Change-Id: Ia3e5e998d1fff44f2e08a240a8769b7ebe794da2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696661
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72906}
      5b783479
  34. 19 Feb, 2021 1 commit
  35. 12 Feb, 2021 2 commits
    • Benedikt Meurer's avatar
      [inspector][stack-traces] Remove support for "displayName". · a9b6f3f7
      Benedikt Meurer authored
      As outlined in the design document linked below, we're removing the
      support for the non-standard Function.displayName property for the
      purpose of Error.stack and DevTools Inspector stack traces. The
      motivation here is that the negative lookup is costly, and we have
      Function.name as a standard alternative (configurable since ES6 for
      exactly this reason).
      
      I dediced to go with JSFunction::GetDebugName(), since
      JSFunction::GetName() was confusing in that it'd only get the "name"
      property's value if it's a data property, but not with accessors.
      JSFunction::GetDebugName() makes it clear that this is really a debug
      helper function and might not give you the "name" property value.
      
      Doc: https://bit.ly/devtools-function-displayName-removal
      Bug: v8:8742, chromium:1177685, chromium:1077657, chromium:17356
      Change-Id: I7717585cbace626174b2f2ed2a4f68f75429eca1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692189
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72715}
      a9b6f3f7
    • Leszek Swirski's avatar
      [sparkplug] Change Sparkplug to Baseline · c913ef3a
      Leszek Swirski authored
      Currently we sometimes refer to baseline code or the baseline compiler
      by its codename (Sparkplug). The codename is fun, but we should be
      consistent and call things by one name or the other. Following the
      pattern of Ignition stuff being called "interpreter", we call Sparkplug
      "baseline", and leave the codename only in flags and variants.
      
      Bug: v8:11420
      Change-Id: I432e5629518be7c7ad38b6acff024c91d4cfd6d3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692186
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72696}
      c913ef3a