1. 24 May, 2022 1 commit
    • Clemens Backes's avatar
      [wasm] Fix return value of lazy compile runtime function · 22a16bda
      Clemens Backes authored
      The Runtime_WasmCompileLazy function was returning a ptr-sized address,
      wrapped in an Object. This worked because no GC is triggered between the
      return from the runtime function and the point where we jump to the
      returned address.
      
      In a pointer-compressed world though, generated code assumes that all
      objects live in the same 4GB heap, so comparisons only compare the lower
      32 bit. On a 64-bit system, this can lead to collisions where a
      comparison determines that the returned address equals a heap object,
      even though the upper 32-bit differ.
      
      This happens occasionally in the wild, where the returned function entry
      pointer has the same lower half than the exception sentinel value. This
      leads to triggering stack unwinding (by the CEntry stub), which then
      fails (with a CHECK) because there is no pending exception.
      
      This CL fixes that by returning a Smi instead which is the offset in the
      jump table where the kWasmCompileLazy builtin should jump to. The
      builtin then gets the jump table start address from the instance object,
      adds the offset that the runtime function returned, and performs the
      jump.
      
      We do not include a regression test because this failure is very
      spurious and hard to reproduce.
      
      R=jkummerow@chromium.org
      
      Bug: chromium:1311960
      Change-Id: I5a72daf78905904f8ae8ade8630793c42e223984
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663093
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80729}
      22a16bda
  2. 13 May, 2022 1 commit
  3. 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
  4. 06 May, 2022 1 commit
  5. 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
  6. 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
  7. 28 Apr, 2022 1 commit
    • Simon Zünd's avatar
      [builtins] Add 'RestartFrameTrampoline' · b0118171
      Simon Zünd authored
      Doc: https://bit.ly/revive-restart-frame
      Context: https://crrev.com/c/3582395 (jumbo CL with the whole feature)
      
      This CL adds a new builtin called "RestartFrameTrampoline". This
      trampoline is relatively simple: It leaves the current frame and
      re-invokes the function. This essentially restarts the function and
      is one of the key components required to bring back the "Restart
      frame" DevTools debugging feature.
      
      The builtin is closely related to the "FrameDropperTrampoline"
      removed in the CL https://crrev.com/c/2854750. The key difference
      is that the "FrameDropperTrampoline" dropped to an "arbitrary"
      frame pointer before restarting the function (arbitrary in the
      sense that it was provided as an argument). This caused issues
      as the feature was implemented in a way that the frame pointer
      wasn't necessarily valid anymore.
      
      In comparison, the "RestartFrameTrampoline" relies on the V8
      unwinder to drop it in the correct frame first and is then
      invoked via either the CEntry stub or the deoptimizer
      (see design doc for details).
      
      Bug: chromium:1303521
      Change-Id: I7bd46620808f8694c2c776b8bcd267e525d5b581
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585944
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80254}
      b0118171
  8. 27 Apr, 2022 1 commit
  9. 26 Apr, 2022 2 commits
    • 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
    • Liu Yu's avatar
      [osr] Load FeedbackVector::kFlagsOffset by load_halfword · 7095683a
      Liu Yu authored
      The size of flag is now 16 bits.
      
      Bug: v8:12161
      Change-Id: I5db5e05171281f27cce739c7b76e1d4b9ebf20b9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602236Reviewed-by: 's avatarJakob Linke <jgruber@chromium.org>
      Commit-Queue: Yu Liu <liuyu@loongson.cn>
      Cr-Commit-Position: refs/heads/main@{#80165}
      7095683a
  10. 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
  11. 14 Apr, 2022 1 commit
  12. 13 Apr, 2022 2 commits
  13. 11 Apr, 2022 1 commit
    • 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
  14. 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
  15. 06 Apr, 2022 1 commit
  16. 05 Apr, 2022 1 commit
  17. 04 Apr, 2022 2 commits
  18. 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
  19. 29 Mar, 2022 1 commit
  20. 21 Mar, 2022 1 commit
  21. 17 Mar, 2022 1 commit
  22. 14 Mar, 2022 1 commit
  23. 25 Feb, 2022 1 commit
  24. 24 Feb, 2022 1 commit
  25. 17 Feb, 2022 1 commit
    • Thibaud Michaud's avatar
      [wasm] Handle arguments in stack-switching export wrapper · 921135c7
      Thibaud Michaud authored
      Use the existing generic js-to-wasm wrapper to handle arguments in
      the stack-switching export wrapper, by combining them into a single
      helper function parameterized by a boolean.
      
      If the stack_switch parameter is false, the generated js-to-wasm wrapper
      is the same as before.
      
      If the stack_switch parameter is true, we allocate and switch to the new
      stack before starting to process the parameters. To load the parameters,
      we also keep a pointer to the old stack.
      After the call, we convert the return value according to the return type
      as usual, and then switch back to the parent stack (which may be
      different than the original stack, but has a compatible stack frame
      layout).
      If the stack suspends during the call, control-flow jumps right before
      we deconstruct and leave the frame, and returns the Promise as an
      externref in the return register.
      
      R=ahaas@chromium.org,jkummerow@chromium.org
      CC=fgm@chromium.org
      
      Bug: v8:12191
      Change-Id: If3f8eaba8edebe6e98d4738f79f895fdb5322adc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3460410Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79148}
      921135c7
  26. 15 Feb, 2022 2 commits
  27. 03 Feb, 2022 1 commit
    • Thibaud Michaud's avatar
      Reland "Reland "[wasm] Resume suspender on resolved promise"" · dfbe5028
      Thibaud Michaud authored
      This is a reland of f942f656
      
      Changes: Change the order of initialization for wasm continuations to
      ensure object integrity if a GC happens during allocation. Also add
      missing handles.
      
      Original change's description:
      > Reland "[wasm] Resume suspender on resolved promise"
      >
      > This is a reland of a865d16b
      >
      > Changes:
      > - Make the next ID atomic
      > - Leave more space for runtime calls in debug mode
      >
      > Original change's description:
      > > [wasm] Resume suspender on resolved promise
      > >
      > > Implement the WasmResume builtin, which resumes a wasm suspender
      > > when the corresponding JS promise resolves.
      > >
      > > Drive-by 1: Fix detection of empty stacks in the stack frame iterator.
      > > Drive-by 2: Add a stack ID for better tracing.
      > >
      > > R=ahaas@chromium.org
      > > CC=​fgm@chromium.org
      > >
      > > Bug: v8:12191
      > > Change-Id: Ifa3f00c4259f802292b04d426c739e9b551f87b9
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3420827
      > > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      > > Cr-Commit-Position: refs/heads/main@{#78842}
      >
      > Bug: v8:12191
      > Change-Id: I3c231690b27be79a0c00e13043342bb4a3628886
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3427203
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78890}
      
      Bug: v8:12191
      Change-Id: I0e1362d3a9da1fd8c0d600ad9776ce2fd26c6a52
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3434145Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78922}
      dfbe5028
  28. 01 Feb, 2022 2 commits
    • Thibaud Michaud's avatar
      Revert "Reland "[wasm] Resume suspender on resolved promise"" · cb12a3e4
      Thibaud Michaud authored
      This reverts commit f942f656.
      
      Reason for revert: Breaks gc-stress
      
      Original change's description:
      > Reland "[wasm] Resume suspender on resolved promise"
      >
      > This is a reland of a865d16b
      >
      > Changes:
      > - Make the next ID atomic
      > - Leave more space for runtime calls in debug mode
      >
      > Original change's description:
      > > [wasm] Resume suspender on resolved promise
      > >
      > > Implement the WasmResume builtin, which resumes a wasm suspender
      > > when the corresponding JS promise resolves.
      > >
      > > Drive-by 1: Fix detection of empty stacks in the stack frame iterator.
      > > Drive-by 2: Add a stack ID for better tracing.
      > >
      > > R=ahaas@chromium.org
      > > CC=​fgm@chromium.org
      > >
      > > Bug: v8:12191
      > > Change-Id: Ifa3f00c4259f802292b04d426c739e9b551f87b9
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3420827
      > > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      > > Cr-Commit-Position: refs/heads/main@{#78842}
      >
      > Bug: v8:12191
      > Change-Id: I3c231690b27be79a0c00e13043342bb4a3628886
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3427203
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78890}
      
      Bug: v8:12191
      Change-Id: I5037419b6cee7a3bb49c1649e5a5d11a935a9b28
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Auto-submit: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3429500
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Auto-Submit: Thibaud Michaud <thibaudm@chromium.org>
      Owners-Override: Maya Lekova <mslekova@chromium.org>
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78893}
      cb12a3e4
    • Thibaud Michaud's avatar
      Reland "[wasm] Resume suspender on resolved promise" · f942f656
      Thibaud Michaud authored
      This is a reland of a865d16b
      
      Changes:
      - Make the next ID atomic
      - Leave more space for runtime calls in debug mode
      
      Original change's description:
      > [wasm] Resume suspender on resolved promise
      >
      > Implement the WasmResume builtin, which resumes a wasm suspender
      > when the corresponding JS promise resolves.
      >
      > Drive-by 1: Fix detection of empty stacks in the stack frame iterator.
      > Drive-by 2: Add a stack ID for better tracing.
      >
      > R=ahaas@chromium.org
      > CC=​fgm@chromium.org
      >
      > Bug: v8:12191
      > Change-Id: Ifa3f00c4259f802292b04d426c739e9b551f87b9
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3420827
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78842}
      
      Bug: v8:12191
      Change-Id: I3c231690b27be79a0c00e13043342bb4a3628886
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3427203Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78890}
      f942f656
  29. 28 Jan, 2022 2 commits
    • Thibaud Michaud's avatar
      Revert "[wasm] Resume suspender on resolved promise" · 98db248d
      Thibaud Michaud authored
      This reverts commit a865d16b.
      
      Reason for revert: breaks tsan and gc-stress
      
      Original change's description:
      > [wasm] Resume suspender on resolved promise
      >
      > Implement the WasmResume builtin, which resumes a wasm suspender
      > when the corresponding JS promise resolves.
      >
      > Drive-by 1: Fix detection of empty stacks in the stack frame iterator.
      > Drive-by 2: Add a stack ID for better tracing.
      >
      > R=​ahaas@chromium.org
      > CC=​​fgm@chromium.org
      >
      > Bug: v8:12191
      > Change-Id: Ifa3f00c4259f802292b04d426c739e9b551f87b9
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3420827
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78842}
      
      Bug: v8:12191
      Change-Id: I3352c8b1dcc8d99e1bd782a09276add219a3ecda
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3424489
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Owners-Override: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78845}
      98db248d
    • Thibaud Michaud's avatar
      [wasm] Resume suspender on resolved promise · a865d16b
      Thibaud Michaud authored
      Implement the WasmResume builtin, which resumes a wasm suspender
      when the corresponding JS promise resolves.
      
      Drive-by 1: Fix detection of empty stacks in the stack frame iterator.
      Drive-by 2: Add a stack ID for better tracing.
      
      R=ahaas@chromium.org
      CC=​fgm@chromium.org
      
      Bug: v8:12191
      Change-Id: Ifa3f00c4259f802292b04d426c739e9b551f87b9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3420827Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78842}
      a865d16b
  30. 27 Jan, 2022 3 commits