1. 13 Jun, 2022 1 commit
  2. 08 Jun, 2022 2 commits
  3. 07 Jun, 2022 1 commit
  4. 31 May, 2022 1 commit
  5. 24 May, 2022 1 commit
  6. 23 May, 2022 1 commit
  7. 20 May, 2022 1 commit
  8. 17 May, 2022 2 commits
  9. 16 May, 2022 2 commits
  10. 12 May, 2022 2 commits
  11. 03 May, 2022 1 commit
  12. 02 May, 2022 2 commits
    • Patrick Thier's avatar
      [string] Fix string table lookup with SlicedStrings · ee247818
      Patrick Thier authored
      https://crrev.com/c/3571817 introduced a bug that string table lookups
      failed on SlicedStrings with a start offset of 0.
      This CL fixes the issue by re-using the already computed hash only
      if the length of the source string matches the length of the string to
      lookup.
      
      Bug: chromium:1320179, chromium:1321573
      Change-Id: Ic8755a0266a9ec67fe5eb9c96fdab1b55d5009f2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616723
      Auto-Submit: Patrick Thier <pthier@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80309}
      ee247818
    • 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
  13. 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
  14. 27 Apr, 2022 1 commit
  15. 26 Apr, 2022 2 commits
    • Jakob Kummerow's avatar
      [wasm-gc] Fix roundtrips of JS functions through Wasm · bac984e6
      Jakob Kummerow authored
      When passing anyref-typed things to Wasm, we cannot expect that
      all functions are WasmExternalFunctions. Instead of adding a
      relatively expensive type check to such calls, this patch disables
      function unwrapping for anyref-typed values.
      
      Fixed: v8:12789
      Change-Id: Ied57187bac7fde0326634f7b4fc428ad21dc9c2f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605231
      Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80179}
      bac984e6
    • 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
  16. 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
  17. 20 Apr, 2022 1 commit
  18. 12 Apr, 2022 1 commit
  19. 11 Apr, 2022 1 commit
  20. 07 Apr, 2022 1 commit
  21. 06 Apr, 2022 3 commits
  22. 04 Apr, 2022 3 commits
    • 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
    • Nikolaos Papaspyrou's avatar
      test: Remove two obsolete regression tests · 173885cd
      Nikolaos Papaspyrou authored
      This CL removes two obsolete regression tests that were taking too
      long on debug engine builds.
      
      Bug: v8:12753
      Bug: v8:12754
      Change-Id: I818101725caa22fb4b2ed22381f01a2dd9436fe4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563563Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79727}
      173885cd
    • jameslahm's avatar
      [runtime] Check AvailableOptimizedCode in DisassembleFunction · 6693641e
      jameslahm authored
      In DisassembleFunction runtime, function may have available
      optimized code and we could directly set the optimized code
      for the function like in CompileLazy if it's not compiled,
      which avoids calling Compiler::Compile and failed in
      DCHECK(!function->HasAvailableOptimizedCode()).
      
      Bug: v8:12762
      Change-Id: I00001fc598f3fc96dfe86b2367e8ba88f0085fd3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563448Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79722}
      6693641e
  23. 01 Apr, 2022 2 commits
    • Thibaud Michaud's avatar
      [sim] Increase the simulator's stack limit margin · d36f596e
      Thibaud Michaud authored
      The current safety margin between the JS stack limit and the actual
      boundary of the stack space reserved by the simulator can be overrun by
      a large frame.
      Raise this margin to 4KiB, corresponding to the "large frame" threshold.
      This ensures that the stack check is executed before the frame is
      allocated if the frame is larger than this margin.
      
      R=clemensb@chromium.org
      
      Bug: chromium:1308333
      Change-Id: I3e1a51bb36c630c7e37e58679971392dada2a83e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560435Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79711}
      d36f596e
    • 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
  24. 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
  25. 29 Mar, 2022 1 commit
  26. 28 Mar, 2022 1 commit
  27. 24 Mar, 2022 2 commits
    • Nico Hartmann's avatar
      [turbofan] Fix a rare false positive in SLVerifier · fa374fc9
      Nico Hartmann authored
      Bug: chromium:1309769, v8:12619
      Change-Id: I880c7326f2ec91f1aa985d6b7ed67f8f5afc074b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548897
      Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79608}
      fa374fc9
    • Joyee Cheung's avatar
      [ic] fix handling of existing properties in Define{Keyed|Named}OwnIC · 4ee68d81
      Joyee Cheung authored
      - When the property being defined with DefineKeyedOwnIC or
        DefineNamedOwnIC already exists, we should use the slow path to
        check if the operation is allowed in case the property is
        non-configurable or Object.preventExtensions() has been called on
        the property.
      - Since KeyedStoreIC:Store() reuses StoreIC::Store() when the key is a
        name, we should use Runtime::DefineObjectOwnProperty() for
        DefineKeyedOwnIC too.
      - When dealing with public fields, Runtime::DefineObjectOwnProperty()
        should use JSReceiver::CreateDataProperty() instead of
        Object::SetProperty() for the specified semantics. This patch also
        adds JSReceiver::AddPrivateField() for it and StoreIC::Store to
        define private fields without triggering traps or checking
        extensibility.
      - To emit a more specific error message when redefining properties
        on non-extensible objects, Object::AddDataProperty() now also takes
        a EnforceDefineSemantics enum to distinguish between set and define.
      - Drive-by: fix JSReceiver::CheckIfCanDefine() which should check for
        extensibility even if the configurability check passes.
      
      Bug: chromium:1259950, v8:9888
      Change-Id: Ib1bc851ffd4b9c3a0e98cac96dafe743c08ee37e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3517934Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#79603}
      4ee68d81