Skip to content

V
V8
Switch branch/tag
  1. 23 Aug, 2022 1 commit
    • wenqin.yang's avatar
      [Interpreter]Elide redundant load context bytecode · c4a0e4a1
      wenqin.yang authored 
      We found there are redundant load context operations in
some bytecode array.

like this:
LdaImmutableCurrentContextSlot [1]
Star0
......   (don’t edit accumulator)
LdaImmutableCurrentContextSlot [1]
Star1
Add r1

In that case, we could modify this bytecode array as:
LdaImmutableCurrentContextSlot [1]
Star0
......   (don’t edit accumulator)
Add r0

This CL will elide these redundant bytecodes
(LdaImmutableCurrentContextSlot and Star1), because there is no
side effect for loading context, and this context slot is immutable.

Change-Id: Ia26f4b934d3bd1d48c50c0c4699ba7942939991c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3816221Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82641}
      c4a0e4a1
  3. 17 Aug, 2022 1 commit
  5. 16 Aug, 2022 2 commits
    • Danylo Boiko's avatar
      [turbofan] Print bytecode sources in --trace-turbo output · d0cd940f
      Danylo Boiko authored 
      Bug: v8:7327
Change-Id: Ia0b768fe6a08c6e628fb91ac489556ddedf120ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3805662Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Commit-Queue: Danylo Boiko <danielboyko02@gmail.com>
Cr-Commit-Position: refs/heads/main@{#82496}
      d0cd940f
    • Simon Zünd's avatar
      [debug] Fix source position around class literals · 6a8b90c3
      Simon Zünd authored 
      This CL builds upon https://crrev.com/c/3284887 (and partly reverts it).

Class literals are a bit iffy when it comes to source position and
debugging. Mainly the debugger assumes the following invariant:
When we are paused inside a class scope, then we expect the class's
BlockContext to be pushed already. On the other hand, when we are
paused outside a class scope in a function, we don't expect to find
the class's BlockContext.

The problem is that there are cases where we can either pause
"inside" or "outside" the class scope. E.g.:

  * `var x = class {};` will break on `class` which is inside
    the class scope, so we expect the BlockContext to be pushed

  * `new class x {};` will break on `new` which is outside the
    class scope, so we expect the BlockContext to not be pushed
    yet.

The issue with the fix in https://crrev.com/c/3284887 is that it
adjusted the break position for the bytecode of class literals to
ALWAYS be after the BlockContext is pushed. This breaks the
second example above. We need to tighten the fix a bit and only
defer the break position if the "current source position" is
inside the class's scope. This way we always guarantee that the
BlockContext is pushed or not, depending if the source position
that corresponds to the break position is inside or outside the
class's scope.

Note 1: The CL updates a lot of the bytecode expectations. This
is because the class literals are often the first statement in
the snippet so we don't need to defer the break position.

Note 2: We add a mirrored debugger test to the inspector test so
the fuzzer can have some more fun.

Fixed: chromim:1350842
Change-Id: I9b5a409f77be80db674217a685a3fc9f8a0a71cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827871Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Reviewed-by: 's avatarKim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82473}
      6a8b90c3
  7. 05 Aug, 2022 1 commit
  9. 04 Aug, 2022 1 commit
  11. 03 Aug, 2022 1 commit
  13. 01 Aug, 2022 1 commit
  15. 29 Jul, 2022 1 commit
  17. 25 Jul, 2022 1 commit
  19. 20 Jul, 2022 1 commit
  21. 08 Jul, 2022 1 commit
  23. 05 Jul, 2022 3 commits
  25. 14 Jun, 2022 1 commit
  27. 09 Jun, 2022 1 commit
  29. 23 May, 2022 1 commit
  31. 13 May, 2022 1 commit
  33. 10 May, 2022 1 commit
  35. 03 May, 2022 1 commit
  37. 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
  39. 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
  41. 27 Apr, 2022 1 commit
  43. 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
  45. 25 Apr, 2022 3 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
    • jameslahm's avatar
      Reland "[interpreter] Optimize strict equal boolean" · fce1047f
      jameslahm authored 
      This is a reland of commit 62632c08.
Reason for previous revert: Performance regressions crbug.com/1315724.
The reland only optimizes strict equal boolean literal like "a===true"
or "a===false", and we generate TestReferenceEqual rather than
TestStrictEqual for the comparasion. And also add typed optimization
for ReferenceEqual when all inputs are boolean with boolean constant.

Original change's description:
> [interpreter] Optimize strict equal boolean
>
> For strict equal boolean literal like "a===true"
> or "a===false", we could generate TestReferenceEqual
> rather than TestStrictEqual. And in `execution_result()->IsTest()`
> case, we could directly emit JumpIfTrue/JumpIfFalse.
>
> E.g.
> ```
> a === true
> ```
> Generated Bytecode From:
> ```
> LdaGlobal
> Star1
> LdaTrue
> TestEqualStrict
> ```
> To:
> ```
> LdaGlobal
> Star1
> LdaTrue
> TestReferenceEqual
> ```
>
> E.g.
> ```
> if (a === true)
> ```
> Generated Bytecode From:
> ```
> LdaGlobal
> Star1
> LdaTrue
> TestEqualStrict
> JumpIfFalse
> ```
> To
> ```
> LdaGlobal
> JumpIfTrue
> Jump
> ```
>
>
> Bug: v8:6403
> Change-Id: Ieaca147acd2d523ac0d2466e7861afb2d29a1310
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568923
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: 王澳 <wangao.james@bytedance.com>
> Cr-Commit-Position: refs/heads/main@{#79935}

Bug: v8:6403
Change-Id: I2ae3ab57dce85313af200fa522e3632af5c3a554
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3592039Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80141}
      fce1047f
  47. 22 Apr, 2022 1 commit
  49. 20 Apr, 2022 1 commit
  51. 19 Apr, 2022 1 commit
    • Jakob Linke's avatar
      Revert "[interpreter] Optimize strict equal boolean" · 3b772a23
      Jakob Linke authored 
      This reverts commit 62632c08.

Reason for revert: Performance regressions crbug.com/1315724

Original change's description:
> [interpreter] Optimize strict equal boolean
>
> For strict equal boolean literal like "a===true"
> or "a===false", we could generate TestReferenceEqual
> rather than TestStrictEqual. And in `execution_result()->IsTest()`
> case, we could directly emit JumpIfTrue/JumpIfFalse.
>
> E.g.
> ```
> a === true
> ```
> Generated Bytecode From:
> ```
> LdaGlobal
> Star1
> LdaTrue
> TestEqualStrict
> ```
> To:
> ```
> LdaGlobal
> Star1
> LdaTrue
> TestReferenceEqual
> ```
>
> E.g.
> ```
> if (a === true)
> ```
> Generated Bytecode From:
> ```
> LdaGlobal
> Star1
> LdaTrue
> TestEqualStrict
> JumpIfFalse
> ```
> To
> ```
> LdaGlobal
> JumpIfTrue
> Jump
> ```
>
>
> Bug: v8:6403
> Change-Id: Ieaca147acd2d523ac0d2466e7861afb2d29a1310
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568923
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: 王澳 <wangao.james@bytedance.com>
> Cr-Commit-Position: refs/heads/main@{#79935}

Bug: v8:6403, chromium:1315724
Change-Id: I65c520590093724e838f738c795d229687efb9de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3592752Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80010}
      3b772a23
  53. 14 Apr, 2022 1 commit
  55. 13 Apr, 2022 2 commits
  57. 12 Apr, 2022 1 commit
    • jameslahm's avatar
      [interpreter] Optimize strict equal boolean · 62632c08
      jameslahm authored 
      For strict equal boolean literal like "a===true"
or "a===false", we could generate TestReferenceEqual
rather than TestStrictEqual. And in `execution_result()->IsTest()`
case, we could directly emit JumpIfTrue/JumpIfFalse.

E.g.
```
a === true
```
Generated Bytecode From:
```
LdaGlobal
Star1
LdaTrue
TestEqualStrict
```
To:
```
LdaGlobal
Star1
LdaTrue
TestReferenceEqual
```

E.g.
```
if (a === true)
```
Generated Bytecode From:
```
LdaGlobal
Star1
LdaTrue
TestEqualStrict
JumpIfFalse
```
To
```
LdaGlobal
JumpIfTrue
Jump
```


Bug: v8:6403
Change-Id: Ieaca147acd2d523ac0d2466e7861afb2d29a1310
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568923Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#79935}
      62632c08
  59. 11 Apr, 2022 1 commit
    • Jakob Gruber's avatar
      Reland "[osr] Add an install-by-offset mechanism" · b8473c52
      Jakob Gruber authored 
      This is a reland of commit 51b99213

Fixed in reland:
- bytecode_age was incorrectly still accessed as an int8 (instead
  of int16).
- age and osr state were incorrectly reset on ia32 (16-bit write
  instead of 32-bit).

Original change's description:
> [osr] Add an install-by-offset mechanism
>
> .. for concurrent OSR. There, the challenge is to hit the correct
> JumpLoop bytecode once compilation completes, since execution has
> moved on in the meantime.
>
> This CL adds a new mechanism to request installation at a specific
> bytecode offset. We add a new `osr_install_target` field to the
> BytecodeArray:
>
>   bitfield struct OSRUrgencyAndInstallTarget extends uint16 {
>     osr_urgency: uint32: 3 bit;
>     osr_install_target: uint32: 13 bit;
>   }
>
>   // [...]
>   osr_urgency_and_install_target: OSRUrgencyAndInstallTarget;
>   bytecode_age: uint16;  // Only 3 bits used.
>   // [...]
>
> Note urgency and install target are packed into one 16 bit field,
> we can thus merge both checks into one comparison within JumpLoop.
> Note also that these fields are adjacent to the bytecode age; we
> still reset both OSR state and age with a single (now 32-bit)
> store.
>
> The install target is the lowest 13 bits of the bytecode offset.
> When set, every reached JumpLoop will check `is this my offset?`,
> and if yes, jump into runtime to tier up.
>
> Drive-by: Rename BaselineAssembler::LoadByteField to LoadWord8Field.
>
> Bug: v8:12161
> Change-Id: I275d468b19df3a4816392a2fec0713a8d211ef80
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571812
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79853}

Bug: v8:12161
Change-Id: I7c59b2a2aacb1d7d40fdf39396ec9d8d48b0b9ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578543Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79911}
      b8473c52
  61. 07 Apr, 2022 2 commits
    • Leszek Swirski's avatar
      Revert "[osr] Add an install-by-offset mechanism" · bb5cc0d5
      Leszek Swirski authored 
      This reverts commit 51b99213.

Reason for revert: Speculative revert for MSAN failure  https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/43080/overview

Original change's description:
> [osr] Add an install-by-offset mechanism
>
> .. for concurrent OSR. There, the challenge is to hit the correct
> JumpLoop bytecode once compilation completes, since execution has
> moved on in the meantime.
>
> This CL adds a new mechanism to request installation at a specific
> bytecode offset. We add a new `osr_install_target` field to the
> BytecodeArray:
>
>   bitfield struct OSRUrgencyAndInstallTarget extends uint16 {
>     osr_urgency: uint32: 3 bit;
>     osr_install_target: uint32: 13 bit;
>   }
>
>   // [...]
>   osr_urgency_and_install_target: OSRUrgencyAndInstallTarget;
>   bytecode_age: uint16;  // Only 3 bits used.
>   // [...]
>
> Note urgency and install target are packed into one 16 bit field,
> we can thus merge both checks into one comparison within JumpLoop.
> Note also that these fields are adjacent to the bytecode age; we
> still reset both OSR state and age with a single (now 32-bit)
> store.
>
> The install target is the lowest 13 bits of the bytecode offset.
> When set, every reached JumpLoop will check `is this my offset?`,
> and if yes, jump into runtime to tier up.
>
> Drive-by: Rename BaselineAssembler::LoadByteField to LoadWord8Field.
>
> Bug: v8:12161
> Change-Id: I275d468b19df3a4816392a2fec0713a8d211ef80
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571812
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79853}

Bug: v8:12161
Change-Id: I0c47499544465c80b5b23a492c00ec1c62815caa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576121
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@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@{#79855}
      bb5cc0d5
    • Jakob Gruber's avatar
      [osr] Add an install-by-offset mechanism · 51b99213
      Jakob Gruber authored 
      .. for concurrent OSR. There, the challenge is to hit the correct
JumpLoop bytecode once compilation completes, since execution has
moved on in the meantime.

This CL adds a new mechanism to request installation at a specific
bytecode offset. We add a new `osr_install_target` field to the
BytecodeArray:

  bitfield struct OSRUrgencyAndInstallTarget extends uint16 {
    osr_urgency: uint32: 3 bit;
    osr_install_target: uint32: 13 bit;
  }

  // [...]
  osr_urgency_and_install_target: OSRUrgencyAndInstallTarget;
  bytecode_age: uint16;  // Only 3 bits used.
  // [...]

Note urgency and install target are packed into one 16 bit field,
we can thus merge both checks into one comparison within JumpLoop.
Note also that these fields are adjacent to the bytecode age; we
still reset both OSR state and age with a single (now 32-bit)
store.

The install target is the lowest 13 bits of the bytecode offset.
When set, every reached JumpLoop will check `is this my offset?`,
and if yes, jump into runtime to tier up.

Drive-by: Rename BaselineAssembler::LoadByteField to LoadWord8Field.

Bug: v8:12161
Change-Id: I275d468b19df3a4816392a2fec0713a8d211ef80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571812Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79853}
      51b99213
  63. 31 Mar, 2022 1 commit
    • Leszek Swirski's avatar
      [maglev] Add lazy deopts · 0df9606d
      Leszek Swirski authored 
      Nodes can now hold a LazyDeoptSafepoint which stores the frame state in
case they trigger a lazy deopt. OpProperties have a new CanLazyDeopt
bit, and codegen emits a safepoint table entry + lazy deopt for all
nodes with this bit. Also, we now check the deoptimized code bit on
entry into the maglev compiled function.

An example use of these lazy deopts is added as a PropertyCell fast path
for LdaGlobal, which adds a code dependency on the property cell.

Bug: v8:7700
Change-Id: I663db38dfa7325d38fc6d5f079d263a958074e36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3557251Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarJakob Linke <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79688}
      0df9606d
  65. 23 Mar, 2022 1 commit