1. 09 May, 2022 1 commit
    • Jakob Linke's avatar
      [osr] Extend OSR tracing · 3e43010a
      Jakob Linke authored
      New trace events:
      
      - finished OSR compilation.
      - entry into OSR code.
      
      Since the latter now happens without a trip into runtime, tracing is a
      bit more involved - we need to check FLAG_trace_osr in generated code,
      and call a runtime function if it is set.
      
      Drive-by: Slightly reorganize other OSR tracing.
      
      Bug: v8:12161
      Change-Id: I3096424ca7d47a19802281a0e0a39f7f3394c12b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3629331
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Auto-Submit: Jakob Linke <jgruber@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80420}
      3e43010a
  2. 02 May, 2022 1 commit
    • Jakob Linke's avatar
      Reland "Reland "[osr] Use the new OSR cache"" · 0e9a55d2
      Jakob Linke authored
      This is a reland of commit 91453880
      
      Fixed: properly reference the ClearedValue in CSA (i.e. without
      the cage_base upper 32 bits).
      
      Original change's description:
      > Reland "[osr] Use the new OSR cache"
      >
      > This is a reland of commit 91da3883
      >
      > Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
      > on arm64.
      >
      > Original change's description:
      > > [osr] Use the new OSR cache
      > >
      > > This CL switches over our OSR system to be based on the feedback
      > > vector osr caches.
      > >
      > > - OSRing to Sparkplug is fully separated from OSR urgency. If
      > >   SP code exists, we simply jump to it, no need to maintain an
      > >   installation request.
      > > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
      > >   If a valid target code object exists, we enter it *without*
      > >   calling into runtime to fetch the code object.
      > > - Finally, OSR urgency still remains as the heuristic for
      > >   requesting Turbofan OSR compile jobs. Note it no longer has a
      > >   double purpose of being a generic untargeted installation
      > >   request.
      > >
      > > With the new system in place, we can remove now-unnecessary
      > > hacks:
      > >
      > > - Early OSR tierup is replaced by the standard OSR system. Any
      > >   present OSR code is automatically entered.
      > > - The synchronous OSR compilation fallback is removed. With
      > >   precise installation (= per-JumpLoop-bytecode) we no longer
      > >   have the problem of 'getting unlucky' with JumpLoop/cache entry
      > >   mismatches. Execution has moved on while compiling? Simply spawn
      > >   a new concurrent compile job.
      > > - Remove the synchronous (non-OSR) Turbofan compile request now
      > >   that we always enter available OSR code as early as possible.
      > > - Tiering into Sparkplug no longer messes with OSR state.
      > >
      > > Bug: v8:12161
      > > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
      > > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > > Auto-Submit: Jakob Linke <jgruber@chromium.org>
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Cr-Commit-Position: refs/heads/main@{#80147}
      >
      > Bug: v8:12161
      > Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
      > Auto-Submit: Jakob Linke <jgruber@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80167}
      
      Bug: v8:12161,chromium:1320189
      Change-Id: Ibd9a2ab61f51ebb32a3f5a66f7c602faead71c3e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620273Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80306}
      0e9a55d2
  3. 29 Apr, 2022 1 commit
    • Rohan Pavone's avatar
      Revert "Reland "[osr] Use the new OSR cache"" · 896f6e74
      Rohan Pavone authored
      This reverts commit 91453880.
      
      Reason for revert: Breaking the Fuchsia Deterministic Builder
      
      Original change's description:
      > Reland "[osr] Use the new OSR cache"
      >
      > This is a reland of commit 91da3883
      >
      > Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
      > on arm64.
      >
      > Original change's description:
      > > [osr] Use the new OSR cache
      > >
      > > This CL switches over our OSR system to be based on the feedback
      > > vector osr caches.
      > >
      > > - OSRing to Sparkplug is fully separated from OSR urgency. If
      > >   SP code exists, we simply jump to it, no need to maintain an
      > >   installation request.
      > > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
      > >   If a valid target code object exists, we enter it *without*
      > >   calling into runtime to fetch the code object.
      > > - Finally, OSR urgency still remains as the heuristic for
      > >   requesting Turbofan OSR compile jobs. Note it no longer has a
      > >   double purpose of being a generic untargeted installation
      > >   request.
      > >
      > > With the new system in place, we can remove now-unnecessary
      > > hacks:
      > >
      > > - Early OSR tierup is replaced by the standard OSR system. Any
      > >   present OSR code is automatically entered.
      > > - The synchronous OSR compilation fallback is removed. With
      > >   precise installation (= per-JumpLoop-bytecode) we no longer
      > >   have the problem of 'getting unlucky' with JumpLoop/cache entry
      > >   mismatches. Execution has moved on while compiling? Simply spawn
      > >   a new concurrent compile job.
      > > - Remove the synchronous (non-OSR) Turbofan compile request now
      > >   that we always enter available OSR code as early as possible.
      > > - Tiering into Sparkplug no longer messes with OSR state.
      > >
      > > Bug: v8:12161
      > > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
      > > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > > Auto-Submit: Jakob Linke <jgruber@chromium.org>
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Cr-Commit-Position: refs/heads/main@{#80147}
      >
      > Bug: v8:12161
      > Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
      > Auto-Submit: Jakob Linke <jgruber@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80167}
      
      Bug: v8:12161
      Change-Id: I73e2d98660e9edfbe07a152a14402380ea9227de
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3615219Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
      Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#80287}
      896f6e74
  4. 27 Apr, 2022 1 commit
  5. 26 Apr, 2022 2 commits
    • Jakob Gruber's avatar
      [osr] Opportunistically keep deoptimized OSR code in the cache · 12284536
      Jakob Gruber authored
      .. when deoptimization occurs after the outermost loop containing the
      loop that triggered OSR compilation. The reasoning is that the main
      benefit of OSR'd code is speeding up the OSR'd loop; the speedup of
      the OSR'd loop is assumed to be higher than deoptimization overhead.
      
      This is a slightly modified version of crrev.com/c/3521361, credit
      goes to tao.pan@intel.com for most of the investigation and
      implementation work.
      
      Bug: v8:12161
      Change-Id: Ie729dd5d1df9c7f529a1cf1b9471bb60ce76c41a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607988Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80177}
      12284536
    • Jakob Gruber's avatar
      Reland "[osr] Use the new OSR cache" · 91453880
      Jakob Gruber authored
      This is a reland of commit 91da3883
      
      Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
      on arm64.
      
      Original change's description:
      > [osr] Use the new OSR cache
      >
      > This CL switches over our OSR system to be based on the feedback
      > vector osr caches.
      >
      > - OSRing to Sparkplug is fully separated from OSR urgency. If
      >   SP code exists, we simply jump to it, no need to maintain an
      >   installation request.
      > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
      >   If a valid target code object exists, we enter it *without*
      >   calling into runtime to fetch the code object.
      > - Finally, OSR urgency still remains as the heuristic for
      >   requesting Turbofan OSR compile jobs. Note it no longer has a
      >   double purpose of being a generic untargeted installation
      >   request.
      >
      > With the new system in place, we can remove now-unnecessary
      > hacks:
      >
      > - Early OSR tierup is replaced by the standard OSR system. Any
      >   present OSR code is automatically entered.
      > - The synchronous OSR compilation fallback is removed. With
      >   precise installation (= per-JumpLoop-bytecode) we no longer
      >   have the problem of 'getting unlucky' with JumpLoop/cache entry
      >   mismatches. Execution has moved on while compiling? Simply spawn
      >   a new concurrent compile job.
      > - Remove the synchronous (non-OSR) Turbofan compile request now
      >   that we always enter available OSR code as early as possible.
      > - Tiering into Sparkplug no longer messes with OSR state.
      >
      > Bug: v8:12161
      > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Auto-Submit: Jakob Linke <jgruber@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80147}
      
      Bug: v8:12161
      Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
      Auto-Submit: Jakob Linke <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80167}
      91453880
  6. 25 Apr, 2022 2 commits
    • Nico Hartmann's avatar
      Revert "[osr] Use the new OSR cache" · c34b7b41
      Nico Hartmann authored
      This reverts commit 91da3883.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20arm64%20-%20sim%20-%20pointer%20compression%20-%20builder/21150/overview
      
      Original change's description:
      > [osr] Use the new OSR cache
      >
      > This CL switches over our OSR system to be based on the feedback
      > vector osr caches.
      >
      > - OSRing to Sparkplug is fully separated from OSR urgency. If
      >   SP code exists, we simply jump to it, no need to maintain an
      >   installation request.
      > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
      >   If a valid target code object exists, we enter it *without*
      >   calling into runtime to fetch the code object.
      > - Finally, OSR urgency still remains as the heuristic for
      >   requesting Turbofan OSR compile jobs. Note it no longer has a
      >   double purpose of being a generic untargeted installation
      >   request.
      >
      > With the new system in place, we can remove now-unnecessary
      > hacks:
      >
      > - Early OSR tierup is replaced by the standard OSR system. Any
      >   present OSR code is automatically entered.
      > - The synchronous OSR compilation fallback is removed. With
      >   precise installation (= per-JumpLoop-bytecode) we no longer
      >   have the problem of 'getting unlucky' with JumpLoop/cache entry
      >   mismatches. Execution has moved on while compiling? Simply spawn
      >   a new concurrent compile job.
      > - Remove the synchronous (non-OSR) Turbofan compile request now
      >   that we always enter available OSR code as early as possible.
      > - Tiering into Sparkplug no longer messes with OSR state.
      >
      > Bug: v8:12161
      > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Auto-Submit: Jakob Linke <jgruber@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80147}
      
      Bug: v8:12161
      Change-Id: I4a6955f4f20b6f3b13e98d5600c7c6a5205915bc
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605608
      Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
      Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@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/main@{#80148}
      c34b7b41
    • Jakob Gruber's avatar
      [osr] Use the new OSR cache · 91da3883
      Jakob Gruber authored
      This CL switches over our OSR system to be based on the feedback
      vector osr caches.
      
      - OSRing to Sparkplug is fully separated from OSR urgency. If
        SP code exists, we simply jump to it, no need to maintain an
        installation request.
      - Each JumpLoop checks its dedicated FeedbackVector cache slot.
        If a valid target code object exists, we enter it *without*
        calling into runtime to fetch the code object.
      - Finally, OSR urgency still remains as the heuristic for
        requesting Turbofan OSR compile jobs. Note it no longer has a
        double purpose of being a generic untargeted installation
        request.
      
      With the new system in place, we can remove now-unnecessary
      hacks:
      
      - Early OSR tierup is replaced by the standard OSR system. Any
        present OSR code is automatically entered.
      - The synchronous OSR compilation fallback is removed. With
        precise installation (= per-JumpLoop-bytecode) we no longer
        have the problem of 'getting unlucky' with JumpLoop/cache entry
        mismatches. Execution has moved on while compiling? Simply spawn
        a new concurrent compile job.
      - Remove the synchronous (non-OSR) Turbofan compile request now
        that we always enter available OSR code as early as possible.
      - Tiering into Sparkplug no longer messes with OSR state.
      
      Bug: v8:12161
      Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Auto-Submit: Jakob Linke <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80147}
      91da3883
  7. 11 Apr, 2022 1 commit
    • Jakob Gruber's avatar
      [osr] Fix an invalid DCHECK in %CompileOptimizedOSR · 5e431b98
      Jakob Gruber authored
      This particular branch in CompileOptimizedOSR relies on a precise
      invocation count at counts 0 and 1. The invocation count is unreliable
      not only in the previously described situation (--always-opt), but also
      e.g. when forcing optimization on the first execution through other
      means like %OptimizeFunctionOnNextCall. Let's simply rewrite the
      condition to explicitly exclude kIsInProgress.
      
      Fixed: chromium:1314536
      Change-Id: I27432f689c866bad3b407df7bbf276ec32c25c0d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578644Reviewed-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@{#79913}
      5e431b98
  8. 06 Apr, 2022 1 commit
  9. 04 Apr, 2022 4 commits
    • Jakob Gruber's avatar
      [compiler] Remove ContinuationForConcurrentOptimization · 5f3ed078
      Jakob Gruber authored
      .. to simplify logic within compiler.cc. GetOrCompileOptimized now only
      returns Code object if the requested optimized Code object is available.
      
      This change also required updating CompileLazy to install the
      appropriate Code object before potentially calling CompileOptimized_*
      runtime functions in order to satisfy the is_compiled precondition.
      
      Bug: v8:12161
      Change-Id: I991dbcc0ba8f3d635aa1e1f06e4cffd89e08a47b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3562978Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79762}
      5f3ed078
    • 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
    • Jakob Gruber's avatar
      [deoptimizer] Remove soft deopts · 1ff685d8
      Jakob Gruber authored
      .. since they are the same as eager deopts (% an unused counter).
      
      Fixed: v8:12765
      Change-Id: I2be6210e476ead4ac6629a49259f28321e965867
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565717Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79729}
      1ff685d8
  10. 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
  11. 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
  12. 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
  13. 24 Mar, 2022 1 commit
  14. 17 Mar, 2022 1 commit
  15. 10 Mar, 2022 1 commit
    • Jakob Gruber's avatar
      Revert "[compiler] Don't remove OSR code cache if deoptimizing at out of loop" · 87f80671
      Jakob Gruber authored
      This reverts commit 190b5d95.
      
      Reason for revert: We should understand & fix regressions, see crbug.com/1304870#c9.
      
      Original change's description:
      > [compiler] Don't remove OSR code cache if deoptimizing at out of loop
      >
      > The main purpose of OSR compilation is fasten inner loop execution, the
      > OSR code cache is still correct for loop if optimizing at out of loop,
      > keep OSR code cache can reduce unnecessary slow bytecode execution with
      > feedback collection and avoid re-OSR compilation.
      > This CL can improve JetStream2 case navier-stokes by ~6%.
      >
      > Change-Id: I9518317fb922071b131cab5b56998a0fc198804a
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3494981
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Commit-Queue: Tao Pan <tao.pan@intel.com>
      > Cr-Commit-Position: refs/heads/main@{#79413}
      
      Bug: chromium:1304870
      Change-Id: I8791edc34b66ef9dd0b477d3e340e85b0617ef59
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3515732
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79435}
      87f80671
  16. 09 Mar, 2022 2 commits
  17. 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
  18. 24 Feb, 2022 1 commit
  19. 21 Feb, 2022 2 commits
  20. 15 Feb, 2022 2 commits
  21. 27 Jan, 2022 1 commit
  22. 20 Jan, 2022 1 commit
  23. 16 Dec, 2021 2 commits
  24. 14 Dec, 2021 1 commit
  25. 08 Nov, 2021 3 commits
  26. 06 Sep, 2021 1 commit
  27. 23 Jun, 2021 1 commit
    • Leszek Swirski's avatar
      Reland "[sparkplug] Trigger compilation when a FBV exists" · 6d1d1fbd
      Leszek Swirski authored
      This is a reland of 3296de2f
      It includes pthier@'s fix of overzealous OSR
      
      Original change's description:
      > [sparkplug] Trigger compilation when a FBV exists
      >
      > We were gating baseline compilation on FBV allocation, but in some
      > cases, the feedback vector may be allocated eagerly (notably, if we are
      > logging function events). Instead, unconditionally try baseline
      > compilation after ensuring the feedback vector exists.
      >
      > Bug: v8:11420
      > Change-Id: I1264a1d541a74d4eccb5caf65c360ac23836a1a8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953161
      > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Reviewed-by: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75242}
      
      Bug: v8:11420
      Change-Id: Ia6864856926d6760bbe6c89ee010fa62cf23b6ca
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2976660
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Reviewed-by: 's avatarPatrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75319}
      6d1d1fbd
  28. 22 Jun, 2021 1 commit
  29. 18 Jun, 2021 1 commit