Skip to content

V
V8
Switch branch/tag
  1. 30 Mar, 2022 1 commit
  3. 29 Mar, 2022 1 commit
  5. 24 Mar, 2022 1 commit
  7. 23 Mar, 2022 1 commit
  9. 22 Mar, 2022 1 commit
  11. 21 Mar, 2022 2 commits
  13. 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
  15. 09 Mar, 2022 1 commit
  17. 08 Mar, 2022 1 commit
  19. 03 Mar, 2022 1 commit
    • Leszek Swirski's avatar
      [maglev] Use RegList for free registers · 31abbcfb
      Leszek Swirski authored 
      Store the free registers as a RegList rather than stack of Register
values. This allows us to simplify some of the register freeing logic,
including passing the current free set to nodes for use as temporaries.

Drive-by: Replace ALWAYS_ALLOCATABLE_GENERAL_REGISTERS with
ALLOCATABLE_GENERAL_REGISTERS, which is the more general list (the former
is an implementation detail for optionally reserving a register for
the cage register).

Bug: v8:7700
Change-Id: I666e9a7547c2f4f4e578fbcbb4bd3fe3cb06dac5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497767Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79344}
      31abbcfb
  21. 21 Feb, 2022 2 commits
  23. 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
  25. 20 Jan, 2022 1 commit
  27. 17 Jan, 2022 1 commit
  29. 16 Dec, 2021 1 commit
  31. 14 Dec, 2021 1 commit
  33. 02 Dec, 2021 1 commit
  35. 18 Nov, 2021 1 commit
  37. 12 Nov, 2021 1 commit
  39. 09 Nov, 2021 1 commit
  41. 26 Oct, 2021 1 commit
  43. 22 Sep, 2021 1 commit
  45. 21 Sep, 2021 1 commit
    • Junliang Yan's avatar
      ppc/s390: [isolate-data] Split builtin tables into tiers · dc88bdf3
      Junliang Yan authored 
      Port 06af754c

Original Message:
  .. for more efficient access to builtins from generated code.

  Root-relative accesses tend to be faster and produce more compact
  code when the root-relative offset is small. IsolateData contains
  a few large tables (roots, external references, builtins), resulting
  in very large offsets in general.

  This CL starts by splitting the builtin table into tiers: tier 0
  is a minimal set of perf-critical builtins that should be cheap to
  access. The offset to tier 0 builtins is guaranteed to be small.

  The full builtin table also remains in IsolateData for occasions in
  which we need to lookup builtins by index.

  In future work, we can also split external references and roots into
  tiers.

  On x64, this reduces deopt exit sizes from 7 to 4 bytes and from 12
  to 9 bytes (dynamic map checks / EagerWithResume deopts).

Change-Id: I021d60b20b783da170987ffcf0327b93206f7e5d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172917Reviewed-by: 's avatarMilad Fa <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#76967}
      dc88bdf3
  47. 20 Sep, 2021 1 commit
    • Jakob Gruber's avatar
      [isolate-data] Split builtin tables into tiers · 06af754c
      Jakob Gruber authored 
      .. for more efficient access to builtins from generated code.

Root-relative accesses tend to be faster and produce more compact
code when the root-relative offset is small. IsolateData contains
a few large tables (roots, external references, builtins), resulting
in very large offsets in general.

This CL starts by splitting the builtin table into tiers: tier 0
is a minimal set of perf-critical builtins that should be cheap to
access. The offset to tier 0 builtins is guaranteed to be small.

The full builtin table also remains in IsolateData for occasions in
which we need to lookup builtins by index.

In future work, we can also split external references and roots into
tiers.

On x64, this reduces deopt exit sizes from 7 to 4 bytes and from 12
to 9 bytes (dynamic map checks / EagerWithResume deopts).

Bug: v8:12203,v8:8661
Change-Id: I5a9ed22b0e00682aca1abcf15892ae1458dbdd70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162142
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76947}
      06af754c
  49. 14 Sep, 2021 2 commits
  51. 07 Sep, 2021 1 commit
  53. 06 Sep, 2021 1 commit
  55. 02 Sep, 2021 1 commit
  57. 16 Aug, 2021 1 commit
  59. 11 Aug, 2021 1 commit
  61. 27 Jul, 2021 1 commit
  63. 20 Jul, 2021 1 commit
    • Mythri A's avatar
      Reland "[sparkplug] Support bytecode / baseline code flushing with sparkplug" · 3ae733f9
      Mythri A authored 
      This is a reland of ea55438a. Relanding
after a fix lands here:
https://chromium-review.googlesource.com/c/v8/v8/+/3030711. The failures
were caused because baseline code could be flushed during the process
of deoptimization after we choose which entry (InterpreterEnterAt* /
BaselineEnterAt* ) builtin to use. BaselineEnterAt* builtins expect
baseline code but it could be flushed before we execute the builtin. The
fix is to defer the decision.

Original change's description:
> [sparkplug] Support bytecode / baseline code flushing with sparkplug
>
> Currently with sparkplug we don't flush bytecode / baseline code of
> functions that were tiered up to sparkplug. This CL adds the support to
> flush baseline code / bytecode of functions that have baseline code too.
> This CL:
> 1. Updates the BodyDescriptor of JSFunction to treat the Code field of
> JSFunction as a custom weak pointer where the code is treated as weak if
> the bytecode corresponding to this function is old.
> 2. Updates GC to handle the functions that had a weak code object during
> the atomic phase of GC.
> 3. Updates the check for old bytecode to also consider when there is
> baseline code on the function.
>
> This CL doesn't change any heuristics for flushing. The baseline code
> will be flushed at the same time as bytecode.
>
> Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
> Bug: v8:11947
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75674}

Bug: v8:11947
Change-Id: I63dce4cd9f6271c54049cc09f95d12e2795f15d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035774Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75810}
      3ae733f9
  65. 19 Jul, 2021 1 commit
  67. 12 Jul, 2021 2 commits
    • Mythri Alle's avatar
      Revert "[sparkplug] Support bytecode / baseline code flushing with sparkplug" · a079f057
      Mythri Alle authored 
      This reverts commit ea55438a.

Reason for revert: Likely culprit for these failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20NumFuzz/15494/overview

Original change's description:
> [sparkplug] Support bytecode / baseline code flushing with sparkplug
>
> Currently with sparkplug we don't flush bytecode / baseline code of
> functions that were tiered up to sparkplug. This CL adds the support to
> flush baseline code / bytecode of functions that have baseline code too.
> This CL:
> 1. Updates the BodyDescriptor of JSFunction to treat the Code field of
> JSFunction as a custom weak pointer where the code is treated as weak if
> the bytecode corresponding to this function is old.
> 2. Updates GC to handle the functions that had a weak code object during
> the atomic phase of GC.
> 3. Updates the check for old bytecode to also consider when there is
> baseline code on the function.
>
> This CL doesn't change any heuristics for flushing. The baseline code
> will be flushed at the same time as bytecode.
>
> Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
> Bug: v8:11947
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75674}

Bug: v8:11947
Change-Id: I50535b9a6c6fc39eceb4f6c0e0c84c55bb92f30a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017811Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75679}
      a079f057
    • Mythri A's avatar
      [sparkplug] Support bytecode / baseline code flushing with sparkplug · ea55438a
      Mythri A authored 
      Currently with sparkplug we don't flush bytecode / baseline code of
functions that were tiered up to sparkplug. This CL adds the support to
flush baseline code / bytecode of functions that have baseline code too.
This CL:
1. Updates the BodyDescriptor of JSFunction to treat the Code field of
JSFunction as a custom weak pointer where the code is treated as weak if
the bytecode corresponding to this function is old.
2. Updates GC to handle the functions that had a weak code object during
the atomic phase of GC.
3. Updates the check for old bytecode to also consider when there is
baseline code on the function.

This CL doesn't change any heuristics for flushing. The baseline code
will be flushed at the same time as bytecode.

Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
Bug: v8:11947
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75674}
      ea55438a
  69. 01 Jul, 2021 1 commit
  71. 30 Jun, 2021 1 commit