• 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
..
arm Loading commit data...
arm64 Loading commit data...
ia32 Loading commit data...
loong64 Loading commit data...
mips Loading commit data...
mips64 Loading commit data...
ppc Loading commit data...
riscv64 Loading commit data...
s390 Loading commit data...
x64 Loading commit data...
DEPS Loading commit data...
OWNERS Loading commit data...
baseline-assembler-inl.h Loading commit data...
baseline-assembler.h Loading commit data...
baseline-batch-compiler.cc Loading commit data...
baseline-batch-compiler.h Loading commit data...
baseline-compiler.cc Loading commit data...
baseline-compiler.h Loading commit data...
baseline.cc Loading commit data...
baseline.h Loading commit data...
bytecode-offset-iterator.cc Loading commit data...
bytecode-offset-iterator.h Loading commit data...