Skip to content

V
V8
Switch branch/tag
  1. 12 Sep, 2022 1 commit
  3. 08 Aug, 2022 1 commit
  5. 03 May, 2022 1 commit
  7. 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
  9. 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
  11. 26 Apr, 2022 1 commit
    • 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
  13. 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
  15. 21 Feb, 2022 2 commits
  17. 15 Feb, 2022 1 commit
  19. 20 Oct, 2021 1 commit
  21. 18 Oct, 2021 3 commits
  23. 11 Oct, 2021 1 commit
  25. 27 Aug, 2021 2 commits
  27. 06 Aug, 2021 1 commit
    • Victor Gomes's avatar
      [baseline] Update EstimateInstructionSize · 63be6dde
      Victor Gomes authored 
      Adds a minimum estimated size.

Data suggests that estimated instruction size (+ relocation info size)
is linear to bytecode array length. This CL adds a constant for this
equation. The ratio remains the same.

This is important, because we want to increase success rate of
estimation when compiling on-heap.

When off-heap, we round up the assembler buffer to 4kB, so this CL
will only impact JS functions with more than 585 bytecodes, i.e, the
new added constant will be negligible.

Note: Relocation info (for Sparkplug) is usually so small that it is
not useful to have a separate zone for this.

Bug: v8:11872
Change-Id: I789e72f80b970d1f541965e7ae808b61c8174326
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069155
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76144}
      63be6dde
  29. 04 Aug, 2021 1 commit
  31. 02 Aug, 2021 1 commit
  33. 29 Jul, 2021 1 commit
    • Mythri A's avatar
      [sparkplug] Introduce flush_baseline_code flag · 64556d13
      Mythri A authored 
      Introduce a flush_baseline_code flag to control if baseline code is
flushed or not. Currently flush_baseline_code implies flush_bytecode
as well. So if flush_baseline_code is enabled both bytecode and baseline
code are flushed. If the flag is disabled we only flush bytecode and
not baseline code.

In a follow-up CL we will add support to control baseline and bytecode
flushing independently i.e. we can flush only bytecode / only baseline
code / both.

Bug: v8:11947
Change-Id: I5a90ed38469de64ed1d736d1eaaeabc2985f0783
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059684
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76003}
      64556d13
  35. 20 Jul, 2021 2 commits
    • Mythri A's avatar
      [mjsunit] Fix flush-baseline-code test · 27d01ae0
      Mythri A authored 
      With lazy feedback allocation we don't tier up to baseline early. This
test requires us to tier up to baseline. So add
--lazy_feedback_allocation as a required flag.

Bug: v8:12009
Change-Id: Ibbc1d1cc74ae368ef414f513a0cd46e9bf068186
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3042718
Commit-Queue: Mythri Alle <mythria@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75829}
      27d01ae0
    • 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
  37. 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
  39. 23 Jun, 2021 1 commit
    • Leszek Swirski's avatar
      Reland "[sparkplug] Trigger compilation when a FBV exists" · 6d1d1fbd
      Leszek Swirski authored 
      This is a reland of 3296de2f
It includes pthier@'s fix of overzealous OSR

Original change's description:
> [sparkplug] Trigger compilation when a FBV exists
>
> We were gating baseline compilation on FBV allocation, but in some
> cases, the feedback vector may be allocated eagerly (notably, if we are
> logging function events). Instead, unconditionally try baseline
> compilation after ensuring the feedback vector exists.
>
> Bug: v8:11420
> Change-Id: I1264a1d541a74d4eccb5caf65c360ac23836a1a8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953161
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75242}

Bug: v8:11420
Change-Id: Ia6864856926d6760bbe6c89ee010fa62cf23b6ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2976660
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: 's avatarPatrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75319}
      6d1d1fbd
  41. 22 Jun, 2021 1 commit
  43. 18 Jun, 2021 1 commit
  45. 17 Jun, 2021 1 commit
  47. 10 Jun, 2021 1 commit
  49. 09 Jun, 2021 1 commit
  51. 07 Jun, 2021 1 commit
  53. 02 Jun, 2021 1 commit
  55. 15 Apr, 2021 1 commit
  57. 13 Apr, 2021 1 commit
  59. 07 Apr, 2021 1 commit
  61. 06 Apr, 2021 1 commit
  63. 31 Mar, 2021 1 commit
  65. 30 Mar, 2021 1 commit