1. 13 May, 2022 1 commit
  2. 06 May, 2022 1 commit
  3. 02 May, 2022 3 commits
    • Milad Fa's avatar
      Reland "PPC/S390: Reland "[osr] Use the new OSR cache"" · 9a06f717
      Milad Fa authored
      This is a reland of commit c575e8ae
      
      Original change's description:
      > PPC/S390: Reland "[osr] Use the new OSR cache"
      >
      > Port 91453880
      >
      > Original Commit Message:
      >
      >   This is a reland of commit 91da3883
      >
      >   Original change's description:
      >   > Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
      >   > on arm64.
      >   > Bug: v8:12161
      >
      > Change-Id: I6e63bd5995340bac32654ef12c52d25b496140e3
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607997
      > Reviewed-by: Junliang Yan <junyan@redhat.com>
      > Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
      > Cr-Commit-Position: refs/heads/main@{#80194}
      
      Change-Id: Id5e41c659a3c29a6d22c0393ad0003a24fa1ef5a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3621273
      Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
      Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#80315}
      9a06f717
    • 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
    • Milad Farazmand's avatar
      Revert "PPC/S390: Reland "[osr] Use the new OSR cache"" · 3b5ba5a8
      Milad Farazmand authored
      This reverts commit c575e8ae.
      
      Reason for revert: Original CL reverted https://crrev.com/c/3615219.
      
      Original change's description:
      > PPC/S390: Reland "[osr] Use the new OSR cache"
      >
      > Port 91453880
      >
      > Original Commit Message:
      >
      >   This is a reland of commit 91da3883
      >
      >   Original change's description:
      >   > Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
      >   > on arm64.
      >   > Bug: v8:12161
      >
      > Change-Id: I6e63bd5995340bac32654ef12c52d25b496140e3
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607997
      > Reviewed-by: Junliang Yan <junyan@redhat.com>
      > Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
      > Cr-Commit-Position: refs/heads/main@{#80194}
      
      Change-Id: I977e59238e1f03c21307c1499cde8b567d1e3e2c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620538
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Reviewed-by: 's avatarMilad Farazmand <mfarazma@redhat.com>
      Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#80305}
      3b5ba5a8
  4. 29 Apr, 2022 2 commits
    • 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
    • Junliang Yan's avatar
      ppc64: [baseline] implement EmitReturn · 671dcfac
      Junliang Yan authored
      Change-Id: I7ba5cd6cf1c76f0955b3ad7184af0a9245f66657
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3613765
      Commit-Queue: Junliang Yan <junyan@redhat.com>
      Reviewed-by: 's avatarMilad Farazmand <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#80280}
      671dcfac
  5. 28 Apr, 2022 3 commits
  6. 27 Apr, 2022 2 commits
  7. 26 Apr, 2022 2 commits
    • Milad Fa's avatar
      PPC/S390: Reland "[osr] Use the new OSR cache" · c575e8ae
      Milad Fa authored
      Port 91453880
      
      Original Commit Message:
      
        This is a reland of commit 91da3883
      
        Original change's description:
        > Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
        > on arm64.
        > Bug: v8:12161
      
      Change-Id: I6e63bd5995340bac32654ef12c52d25b496140e3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607997Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
      Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#80194}
      c575e8ae
    • 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
  8. 25 Apr, 2022 4 commits
    • Junliang Yan's avatar
      ppc64: [baseline] implement AddSmi · 07ec534d
      Junliang Yan authored
      Change-Id: I94f3f02e2214437d8320d31c8be24f41698f136c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3604752Reviewed-by: 's avatarMilad Farazmand <mfarazma@redhat.com>
      Commit-Queue: Junliang Yan <junyan@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#80156}
      07ec534d
    • 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
    • Lu Yahan's avatar
      [riscv64] Fix relocation attribute not loaded correctly · e51739dd
      Lu Yahan authored
      And port commit 5ee6b7a7
      
      Change-Id: Ia43d1d888154ebffcd56d436e6dfa8970eae6583
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3600174Reviewed-by: 's avatarji qiu <qiuji@iscas.ac.cn>
      Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
      Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
      Cr-Commit-Position: refs/heads/main@{#80132}
      e51739dd
  9. 21 Apr, 2022 2 commits
  10. 20 Apr, 2022 1 commit
  11. 14 Apr, 2022 1 commit
  12. 13 Apr, 2022 6 commits
  13. 12 Apr, 2022 1 commit
  14. 11 Apr, 2022 2 commits
    • Junliang Yan's avatar
      s390x/ppc64: [osr] Add an install-by-offset mechanism · a3aad69c
      Junliang Yan authored
      Port 52b99213e73045e9ffcae970e6c3f3cd07fc8381
      
      Bug: v8:12161
      Change-Id: Iac4f31eb6be83bca0e4bd407d81f1ece271b1e67
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576124Reviewed-by: 's avatarMilad Farazmand <mfarazma@redhat.com>
      Commit-Queue: Junliang Yan <junyan@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#79917}
      a3aad69c
    • Jakob Gruber's avatar
      Reland "[osr] Add an install-by-offset mechanism" · b8473c52
      Jakob Gruber authored
      This is a reland of commit 51b99213
      
      Fixed in reland:
      - bytecode_age was incorrectly still accessed as an int8 (instead
        of int16).
      - age and osr state were incorrectly reset on ia32 (16-bit write
        instead of 32-bit).
      
      Original change's description:
      > [osr] Add an install-by-offset mechanism
      >
      > .. for concurrent OSR. There, the challenge is to hit the correct
      > JumpLoop bytecode once compilation completes, since execution has
      > moved on in the meantime.
      >
      > This CL adds a new mechanism to request installation at a specific
      > bytecode offset. We add a new `osr_install_target` field to the
      > BytecodeArray:
      >
      >   bitfield struct OSRUrgencyAndInstallTarget extends uint16 {
      >     osr_urgency: uint32: 3 bit;
      >     osr_install_target: uint32: 13 bit;
      >   }
      >
      >   // [...]
      >   osr_urgency_and_install_target: OSRUrgencyAndInstallTarget;
      >   bytecode_age: uint16;  // Only 3 bits used.
      >   // [...]
      >
      > Note urgency and install target are packed into one 16 bit field,
      > we can thus merge both checks into one comparison within JumpLoop.
      > Note also that these fields are adjacent to the bytecode age; we
      > still reset both OSR state and age with a single (now 32-bit)
      > store.
      >
      > The install target is the lowest 13 bits of the bytecode offset.
      > When set, every reached JumpLoop will check `is this my offset?`,
      > and if yes, jump into runtime to tier up.
      >
      > Drive-by: Rename BaselineAssembler::LoadByteField to LoadWord8Field.
      >
      > Bug: v8:12161
      > Change-Id: I275d468b19df3a4816392a2fec0713a8d211ef80
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571812
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79853}
      
      Bug: v8:12161
      Change-Id: I7c59b2a2aacb1d7d40fdf39396ec9d8d48b0b9ac
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578543Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79911}
      b8473c52
  15. 08 Apr, 2022 1 commit
  16. 07 Apr, 2022 2 commits
    • Leszek Swirski's avatar
      Revert "[osr] Add an install-by-offset mechanism" · bb5cc0d5
      Leszek Swirski authored
      This reverts commit 51b99213.
      
      Reason for revert: Speculative revert for MSAN failure  https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/43080/overview
      
      Original change's description:
      > [osr] Add an install-by-offset mechanism
      >
      > .. for concurrent OSR. There, the challenge is to hit the correct
      > JumpLoop bytecode once compilation completes, since execution has
      > moved on in the meantime.
      >
      > This CL adds a new mechanism to request installation at a specific
      > bytecode offset. We add a new `osr_install_target` field to the
      > BytecodeArray:
      >
      >   bitfield struct OSRUrgencyAndInstallTarget extends uint16 {
      >     osr_urgency: uint32: 3 bit;
      >     osr_install_target: uint32: 13 bit;
      >   }
      >
      >   // [...]
      >   osr_urgency_and_install_target: OSRUrgencyAndInstallTarget;
      >   bytecode_age: uint16;  // Only 3 bits used.
      >   // [...]
      >
      > Note urgency and install target are packed into one 16 bit field,
      > we can thus merge both checks into one comparison within JumpLoop.
      > Note also that these fields are adjacent to the bytecode age; we
      > still reset both OSR state and age with a single (now 32-bit)
      > store.
      >
      > The install target is the lowest 13 bits of the bytecode offset.
      > When set, every reached JumpLoop will check `is this my offset?`,
      > and if yes, jump into runtime to tier up.
      >
      > Drive-by: Rename BaselineAssembler::LoadByteField to LoadWord8Field.
      >
      > Bug: v8:12161
      > Change-Id: I275d468b19df3a4816392a2fec0713a8d211ef80
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571812
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79853}
      
      Bug: v8:12161
      Change-Id: I0c47499544465c80b5b23a492c00ec1c62815caa
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576121
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Owners-Override: Leszek Swirski <leszeks@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@{#79855}
      bb5cc0d5
    • Jakob Gruber's avatar
      [osr] Add an install-by-offset mechanism · 51b99213
      Jakob Gruber authored
      .. for concurrent OSR. There, the challenge is to hit the correct
      JumpLoop bytecode once compilation completes, since execution has
      moved on in the meantime.
      
      This CL adds a new mechanism to request installation at a specific
      bytecode offset. We add a new `osr_install_target` field to the
      BytecodeArray:
      
        bitfield struct OSRUrgencyAndInstallTarget extends uint16 {
          osr_urgency: uint32: 3 bit;
          osr_install_target: uint32: 13 bit;
        }
      
        // [...]
        osr_urgency_and_install_target: OSRUrgencyAndInstallTarget;
        bytecode_age: uint16;  // Only 3 bits used.
        // [...]
      
      Note urgency and install target are packed into one 16 bit field,
      we can thus merge both checks into one comparison within JumpLoop.
      Note also that these fields are adjacent to the bytecode age; we
      still reset both OSR state and age with a single (now 32-bit)
      store.
      
      The install target is the lowest 13 bits of the bytecode offset.
      When set, every reached JumpLoop will check `is this my offset?`,
      and if yes, jump into runtime to tier up.
      
      Drive-by: Rename BaselineAssembler::LoadByteField to LoadWord8Field.
      
      Bug: v8:12161
      Change-Id: I275d468b19df3a4816392a2fec0713a8d211ef80
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571812Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79853}
      51b99213
  17. 04 Apr, 2022 1 commit
  18. 28 Mar, 2022 2 commits
  19. 22 Mar, 2022 2 commits
  20. 21 Mar, 2022 1 commit