• 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
Name
Last commit
Last update
..
baseline-assembler-arm64-inl.h Loading commit data...
baseline-compiler-arm64-inl.h Loading commit data...