Skip to content

V
V8
Switch branch/tag
  1. 09 Jun, 2022 1 commit
    • Georgia Kouveli's avatar
      [arm64] Fix CFI issue with short builtin calls · fb235844
      Georgia Kouveli authored 
      The allowlist used for `Deoptimizer::IsValidReturnAddress` depends on
fixed embedded builtin addresses. Pass a pointer to the isolate to
this method, so that it can discover the actual builtin code start
(which may have been remapped) and calculate the offset from the start
of the builtins' code in order to check if the return address is
allowed.

After this change, do not disable short builtin calls when CFI is
enabled.

There's an important TODO for this change:
Since the builtin code pointer that's used to check whether a return
address is allowed is now writable, we should use pointer authentication
to protect it.

Bug: v8:10026
Change-Id: Iafd31d3ad7e10cb17faf33e76e78d3df36edeefd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3667506Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/main@{#81049}
      fb235844
  3. 03 Jun, 2022 1 commit
  5. 17 May, 2022 1 commit
  7. 13 May, 2022 1 commit
  9. 11 May, 2022 1 commit
  11. 10 May, 2022 1 commit
  13. 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
  15. 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
  17. 28 Apr, 2022 2 commits
    • Igor Sheludko's avatar
      Reland "[rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)" · 449ece38
      Igor Sheludko authored 
      This is a reland of commit 9d31f866
There were issues with --future flag implications on M1.

Original change's description:
> [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)
>
> ... for V8 code space. The feature is currently disabled.
>
> In order to use fast W^X permission switching we must allocate
> executable pages with readable writable executable permissions (RWX).
> However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
> permission changing of RWX memory pages. This means that the code page
> headers must be allocated with RWX permissions too because otherwise
> it wouldn't be possible to allocate a large code page over the freed
> regular code page and vice versa.
>
> When enabled, the new machinery works as follows:
>
> 1) when memory region is reserved for allocating executable pages, the
>    whole region is committed with RWX permissions and then decommitted,
> 2) since reconfiguration of RWX page permissions is not allowed on
>    MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
>    to change them,
> 3) the request to set RWX permissions in the executable page region
>    just recommits the pages without changing permissions (see (1), they
>    were already allocated as RWX and then discarded),
> 4) in order to make executable pages inaccessible one must use
>    OS::DiscardSystemPages() instead of OS::DecommitPages() or
>    setting permissions to kNoAccess because the latter two are not
>    allowed by the MacOS (see (2)).
> 5) since code space page headers are allocated as RWX pages it's also
>    necessary to switch between W^X modes when updating the data in the
>    page headers (i.e. when marking, updating stats, wiring pages in
>    lists, etc.). The new CodePageHeaderModificationScope class is used
>    in the respective places. On unrelated configurations it's a no-op.
>
> The fast permission switching can't be used for V8 configuration with
> enabled pointer compression and disabled external code space because
> a) the pointer compression cage has to be reserved with MAP_JIT flag
>    which is too expensive,
> b) in case of shared pointer compression cage if the code range will
>    be deleted while the cage is still alive then attempt to configure
>    permissions of pages that were previously set to RWX will fail.
>
> This also CL extends the unmapper unit tests with permissions tracking
> for discarded pages.
>
> Bug: v8:12797
> Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80238}

Bug: v8:12797
Change-Id: I0fe86666f31bad37d7074e217555c95900d2afba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610433Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80259}
      449ece38
    • Victor Gomes's avatar
      [cleanup] Rename TranslatedFrame with inlined arguments · 4b419c06
      Victor Gomes authored 
      ... from ArgumentsAdaptorFrame to InlinedExtraArguments.

Change-Id: I772e0546dd50282a4cd14723625fd5bf774f424c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3609968Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80250}
      4b419c06
  19. 27 Apr, 2022 3 commits
    • Adam Klein's avatar
      Revert "[rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)" · 10807c9f
      Adam Klein authored 
      This reverts commit 9d31f866.

Reason for revert: crashes on Mac/arm64 bots:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20debug/5923/overview

Original change's description:
> [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)
>
> ... for V8 code space. The feature is currently disabled.
>
> In order to use fast W^X permission switching we must allocate
> executable pages with readable writable executable permissions (RWX).
> However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
> permission changing of RWX memory pages. This means that the code page
> headers must be allocated with RWX permissions too because otherwise
> it wouldn't be possible to allocate a large code page over the freed
> regular code page and vice versa.
>
> When enabled, the new machinery works as follows:
>
> 1) when memory region is reserved for allocating executable pages, the
>    whole region is committed with RWX permissions and then decommitted,
> 2) since reconfiguration of RWX page permissions is not allowed on
>    MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
>    to change them,
> 3) the request to set RWX permissions in the executable page region
>    just recommits the pages without changing permissions (see (1), they
>    were already allocated as RWX and then discarded),
> 4) in order to make executable pages inaccessible one must use
>    OS::DiscardSystemPages() instead of OS::DecommitPages() or
>    setting permissions to kNoAccess because the latter two are not
>    allowed by the MacOS (see (2)).
> 5) since code space page headers are allocated as RWX pages it's also
>    necessary to switch between W^X modes when updating the data in the
>    page headers (i.e. when marking, updating stats, wiring pages in
>    lists, etc.). The new CodePageHeaderModificationScope class is used
>    in the respective places. On unrelated configurations it's a no-op.
>
> The fast permission switching can't be used for V8 configuration with
> enabled pointer compression and disabled external code space because
> a) the pointer compression cage has to be reserved with MAP_JIT flag
>    which is too expensive,
> b) in case of shared pointer compression cage if the code range will
>    be deleted while the cage is still alive then attempt to configure
>    permissions of pages that were previously set to RWX will fail.
>
> This also CL extends the unmapper unit tests with permissions tracking
> for discarded pages.
>
> Bug: v8:12797
> Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80238}

Bug: v8:12797
Change-Id: Ic07948e036db36326d464a2a901d052aa060a406
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3611665
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80239}
      10807c9f
    • Igor Sheludko's avatar
      [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1) · 9d31f866
      Igor Sheludko authored 
      ... for V8 code space. The feature is currently disabled.

In order to use fast W^X permission switching we must allocate
executable pages with readable writable executable permissions (RWX).
However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
permission changing of RWX memory pages. This means that the code page
headers must be allocated with RWX permissions too because otherwise
it wouldn't be possible to allocate a large code page over the freed
regular code page and vice versa.

When enabled, the new machinery works as follows:

1) when memory region is reserved for allocating executable pages, the
   whole region is committed with RWX permissions and then decommitted,
2) since reconfiguration of RWX page permissions is not allowed on
   MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
   to change them,
3) the request to set RWX permissions in the executable page region
   just recommits the pages without changing permissions (see (1), they
   were already allocated as RWX and then discarded),
4) in order to make executable pages inaccessible one must use
   OS::DiscardSystemPages() instead of OS::DecommitPages() or
   setting permissions to kNoAccess because the latter two are not
   allowed by the MacOS (see (2)).
5) since code space page headers are allocated as RWX pages it's also
   necessary to switch between W^X modes when updating the data in the
   page headers (i.e. when marking, updating stats, wiring pages in
   lists, etc.). The new CodePageHeaderModificationScope class is used
   in the respective places. On unrelated configurations it's a no-op.

The fast permission switching can't be used for V8 configuration with
enabled pointer compression and disabled external code space because
a) the pointer compression cage has to be reserved with MAP_JIT flag
   which is too expensive,
b) in case of shared pointer compression cage if the code range will
   be deleted while the cage is still alive then attempt to configure
   permissions of pages that were previously set to RWX will fail.

This also CL extends the unmapper unit tests with permissions tracking
for discarded pages.

Bug: v8:12797
Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80238}
      9d31f866
    • Jakob Gruber's avatar
      [osr] Fix DeoptExitIsInsideOsrLoop in presence of inlining · 4ac65c1b
      Jakob Gruber authored 
      This logic was confused in the presence of inlined frames; the
deopt exit offset would point inside the innermost inlined frame
while we incorrectly assumed it points at the outermost frame.

Fix this by always referring to the bytecode offset of the outermost
frame.

Bug: v8:12161
Fixed: chromium:1320094
Change-Id: I2eb28498639432c5344859f64a9388d93ee23bde
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3608630
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80212}
      4ac65c1b
  21. 26 Apr, 2022 2 commits
    • Jakob Gruber's avatar
      [osr] Opportunistically keep deoptimized OSR code in the cache · 12284536
      Jakob Gruber authored 
      .. when deoptimization occurs after the outermost loop containing the
loop that triggered OSR compilation. The reasoning is that the main
benefit of OSR'd code is speeding up the OSR'd loop; the speedup of
the OSR'd loop is assumed to be higher than deoptimization overhead.

This is a slightly modified version of crrev.com/c/3521361, credit
goes to tao.pan@intel.com for most of the investigation and
implementation work.

Bug: v8:12161
Change-Id: Ie729dd5d1df9c7f529a1cf1b9471bb60ce76c41a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607988Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80177}
      12284536
    • 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
  23. 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
  25. 04 Apr, 2022 2 commits
  27. 01 Apr, 2022 1 commit
    • Adam Klein's avatar
      Revert "Refactor OSROptimizedCodeCache" · b591fccb
      Adam Klein authored 
      This reverts commit d368dcf4.

Reason for revert: https://crbug.com/1312188

Original change's description:
> Refactor OSROptimizedCodeCache
>
> Tweak a few names, remove a few GetIsolate calls, other minor
> usability refactors.
>
> It may be worth taking a closer look at the impl in the future,
> currently the design choices don't seem ideal (see the added TODO
> on top of the class).
>
> Bug: v8:12161
> Change-Id: Ib34e372aa58a30c68c9c5cdd0d1da0ec3e86717c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560447
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79687}

Bug: v8:12161, chromium:1312188
Change-Id: Ieb3a91682845a23536fdfdf3208af74b3c6585f8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3564989
Auto-Submit: Adam Klein <adamk@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@{#79700}
      b591fccb
  29. 31 Mar, 2022 1 commit
  31. 30 Mar, 2022 1 commit
  33. 29 Mar, 2022 1 commit
  35. 24 Mar, 2022 1 commit
  37. 21 Mar, 2022 1 commit
  39. 10 Mar, 2022 1 commit
    • Jakob Gruber's avatar
      Revert "[compiler] Don't remove OSR code cache if deoptimizing at out of loop" · 87f80671
      Jakob Gruber authored 
      This reverts commit 190b5d95.

Reason for revert: We should understand & fix regressions, see crbug.com/1304870#c9.

Original change's description:
> [compiler] Don't remove OSR code cache if deoptimizing at out of loop
>
> The main purpose of OSR compilation is fasten inner loop execution, the
> OSR code cache is still correct for loop if optimizing at out of loop,
> keep OSR code cache can reduce unnecessary slow bytecode execution with
> feedback collection and avoid re-OSR compilation.
> This CL can improve JetStream2 case navier-stokes by ~6%.
>
> Change-Id: I9518317fb922071b131cab5b56998a0fc198804a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3494981
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Tao Pan <tao.pan@intel.com>
> Cr-Commit-Position: refs/heads/main@{#79413}

Bug: chromium:1304870
Change-Id: I8791edc34b66ef9dd0b477d3e340e85b0617ef59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3515732
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79435}
      87f80671
  41. 09 Mar, 2022 1 commit
  43. 21 Feb, 2022 2 commits
  45. 15 Feb, 2022 1 commit
    • Jakob Gruber's avatar
      Remove the OptimizationTier enum · 8bad4516
      Jakob Gruber authored 
      This was mostly unused. We should simply be able to use CodeKind plus
related predicates instead.

Replace FeedbackVector::optimization_tier with
maybe_has_optimized_code, which states whether the optimized code
cache is filled. The value is updated lazily and may lag behind the
actual code cache state. We only use this field for quick cache-empty?
checks from generated code.

Bug: v8:7700,v8:12552
Change-Id: Ibfc5c0128eac56167a68ecba5690eab2e9369640
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3460741Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79107}
      8bad4516
  47. 20 Jan, 2022 1 commit
  49. 17 Jan, 2022 1 commit
  51. 16 Dec, 2021 1 commit
  53. 14 Dec, 2021 1 commit
  55. 02 Dec, 2021 1 commit
  57. 12 Nov, 2021 1 commit
  59. 07 Sep, 2021 1 commit
  61. 06 Sep, 2021 1 commit
  63. 02 Sep, 2021 1 commit
  65. 11 Aug, 2021 1 commit