Skip to content

V
V8
Switch branch/tag
  1. 08 Jul, 2022 1 commit
  3. 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
  5. 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
  7. 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
  9. 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
  11. 22 Apr, 2022 1 commit
  13. 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
  15. 14 Apr, 2022 1 commit
  17. 13 Apr, 2022 2 commits
  19. 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
  21. 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
  23. 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
  25. 17 Mar, 2022 1 commit
  27. 14 Mar, 2022 1 commit
  29. 08 Mar, 2022 1 commit
    • Joyee Cheung's avatar
      [ic] name Set/Define/Store property operations more consistently · 0d1ffe30
      Joyee Cheung authored 
      For background and reasoning, see
https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit
This is the first step towards pulling the DefineNamedOwn operation out
of StoreIC.

Summary of the renamed identifiers:

Bytecodes:

- StaNamedProperty -> SetNamedProperty: calls StoreIC and emitted for
  normal named property sets like obj.x = 1.
- StaNamedOwnProperty -> DefineNamedOwnProperty: calls
  DefineNamedOwnIC (previously StoreOwnIC), and emitted for
  initialization of named properties in object literals and named
  public class fields.
- StaKeyedProperty -> SetKeyedProperty: calls KeyedStoreIC and emitted
  for keyed property sets like obj[x] = 1.
- StaKeyedPropertyAsDefine -> DefineKeyedOwnProperty: calls
  DefineKeyedOwnIC (previously KeyedDefineOwnIC) and emitted for
  initialization of private class fields and computed public class
  fields.
- StaDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral: calls
  DefineKeyedOwnPropertyInLiteral runtime function (previously
  DefineDataPropertyInLiteral) and emitted for initialization of keyed
  properties in object literals and static class initializers. (note
  that previously the StoreDataPropertyInLiteral runtime function name
  was taken by object spreads and array literal creation instead)
- LdaKeyedProperty -> GetKeyedProperty, LdaNamedProperty ->
  GetNamedProperty, LdaNamedPropertyFromSuper ->
  GetNamedPropertyFromSuper: we drop the Sta prefix for the property
  store operations since the accumulator use is implicit and to make
  the wording more natural, for symmetry the Lda prefix for the
  property load operations is also dropped.

opcodes:

- (JS)StoreNamed -> (JS)SetNamedProperty: implements set semantics for
  named properties, compiled from SetNamedProperty (previously
  StaNamedProperty) and lowers to StoreIC or Runtime::kSetNamedProperty
- (JS)StoreNamedOwn -> (JS)DefineNamedOwnProperty: implements define
  semantics for initializing named own properties in object literal and
  public class fields, compiled from DefineNamedOwnProperty (previously
  StaNamedOwnProperty) and lowers to DefineNamedOwnIC
  (previously StoreOwnIC)
- (JS)StoreProperty -> (JS)SetKeyedProperty: implements set semantics
  for keyed properties, only compiled from SetKeyedProperty(previously
  StaKeyedProperty) and lowers to KeyedStoreIC
- (JS)DefineProperty -> (JS)DefineKeyedOwnProperty: implements define
  semantics for initialization of private class fields and computed
  public class fields, compiled from DefineKeyedOwnProperty (previously
  StaKeyedPropertyAsDefine) and calls DefineKeyedOwnIC (previously
  KeyedDefineOwnIC).
- (JS)StoreDataPropertyInLiteral ->
  (JS)DefineKeyedOwnPropertyInLiteral: implements define semantics for
  initialization of keyed properties in object literals and static
  class initializers, compiled from DefineKeyedOwnPropertyInLiteral
  (previously StaDataPropertyInLiteral) and calls the
  DefineKeyedOwnPropertyInLiteral runtime function (previously
  DefineDataPropertyInLiteral).

Runtime:
- DefineDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral:
  following the bytecode/opcodes change, this is used by
  DefineKeyedOwnPropertyInLiteral (previously StaDataPropertyInLiteral)
  for object and class literal initialization.
- StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral_Simple:
  it's just a simplified version of DefineDataPropertyInLiteral that
  does not update feedback or perform function name configuration.
  This is used by object spread and array literal creation. Since we
  are renaming DefineDataPropertyInLiteral to
  DefineKeyedOwnPropertyInLiteral, rename this simplified version with
  a `_Simple` suffix. We can consider merging it into
  DefineKeyedOwnPropertyInLiteral in the future. See
  https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit?disco=AAAAQQIz6mU
- Other changes following the bytecode/IR changes

IC:

- StoreOwn -> DefineNamedOwn: used for initialization of named
  properties in object literals and named public class fields.
  - StoreOwnIC -> DefineNamedOwnIC
  - StoreMode::kStoreOwn -> StoreMode::kDefineNamedOwn
  - StoreICMode::kStoreOwn -> StoreICMode::kDefineNamedOwn
  - IsStoreOwn() -> IsDefineNamedOwn()
- DefineOwn -> DefineKeyedOwn: IsDefineOwnIC() was already just
  IsDefineKeyedOwnIC(), and IsAnyDefineOwn() includes both named and
  keyed defines so we don't need an extra generic predicate.
  - StoreMode::kDefineOwn -> StoreMode::kDefineKeyedOwn
  - StoreICMode::kDefineOwn -> StoreICMode::kDefineKeyedOwn
  - IsDefineOwn() -> IsDefineKeyedOwn()
  - IsDefineOwnIC() -> IsDefineKeyedOwnIC()
  - Removing IsKeyedDefineOwnIC() as its now a duplicate of
    IsDefineKeyedOwnIC()
- KeyedDefineOwnIC -> DefineKeyedOwnIC,
  KeyedDefineOwnGenericGenerator() -> DefineKeyedOwnGenericGenerator:
  make the ordering of terms more consistent
- IsAnyStoreOwn() -> IsAnyDefineOwn(): this includes the renamed and
  DefineNamedOwn and DefineKeyedOwn. Also is_any_store_own() is
  removed since it's just a duplicate of this.
- IsKeyedStoreOwn() -> IsDefineNamedOwn(): it's unclear where the
  "keyed" part came from, but it's only used when DefineNamedOwnIC
  (previously StoreOwnIC) reuses KeyedStoreIC, so rename it accordingly

Interpreter & compiler:
- BytecodeArrayBuilder: following bytecode changes
    - StoreNamedProperty -> SetNamedProperty
  - StoreNamedOwnProperty -> DefineNamedOwnProperty
  - StoreKeyedProperty -> SetKeyedProperty
  - DefineKeyedProperty -> DefineKeyedOwnProperty
  - StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral
- FeedbackSlotKind:
  - kDefineOwnKeyed -> kDefineKeyedOwn: make the ordering of terms more
    consistent
  - kStoreOwnNamed -> kDefineNamedOwn: following the IC change
  - kStoreNamed{Sloppy|Strict} -> kSetNamed{Sloppy|Strict}: only
    used in StoreIC for set semantics
  - kStoreKeyed{Sloppy|Strict} -> kSetKeyed{Sloppy|Strict}: only used
    in KeyedStoreIC for set semantics
  - kStoreDataPropertyInLiteral -> kDefineKeyedOwnPropertyInLiteral:
    following the IC change
- BytecodeGraphBuilder
  - StoreMode::kNormal, kOwn -> NamedStoreMode::kSet, kDefineOwn: this
    is only used by BytecodeGraphBuilder::BuildNamedStore() to tell the
    difference between SetNamedProperty and DefineNamedOwnProperty
    operations.

Not changed:

- StoreIC and KeyedStoreIC currently contain mixed logic for both Set
  and Define operations, and the paths are controlled by feedback. The
  plan is to refactor the hierarchy like this:
  ```
  - StoreIC
    - DefineNamedOwnIC
    - SetNamedIC (there could also be a NamedStoreIC if that's helpful)
    - KeyedStoreIC
      - SetKeyedIC
      - DefineKeyedOwnIC
      - DefineKeyedOwnICLiteral (could be merged into DefineKeyedOwnIC)
      - StoreInArrayLiteralIC
    - ...
  ```
  StoreIC and KeyedStoreIC would then contain helpers shared by their
  subclasses, therefore it still makes sense to keep the word "Store"
  in their names since they would be generic base classes for both set
  and define operations.
- The Lda and Sta prefixes of bytecodes not involving object properties
  (e.g. Ldar, Star, LdaZero) are kept, since this patch focuses on
  property operations, and distinction between Set and Define might be
  less relevant or nonexistent for bytecodes not involving object
  properties. We could consider rename some of them in future patches
  if that's helpful though.

Bug: v8:12548
Change-Id: Ia36997b02f59a87da3247f20e0560a7eb13077f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3481475Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#79409}
      0d1ffe30
  31. 06 Dec, 2021 1 commit
  33. 02 Dec, 2021 1 commit
  35. 25 Nov, 2021 1 commit
  37. 10 Nov, 2021 2 commits
  39. 13 Oct, 2021 1 commit
    • Joyee Cheung's avatar
      [class] Add IC support for defining class fields to replace runtime call · 713ebae3
      Joyee Cheung authored 
      Introduces several new runtime mechanics for defining private fields,
including:
  - Bytecode StaKeyedPropertyAsDefine
  - Builtins StoreOwnIC{Trampoline|Baseline|_NoFeedback}
  - Builtins KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic}
  - TurboFan IR opcode JSDefineProperty

These new operations can reduce a runtime call per class field into a
more traditional Store equivalent. In the microbenchmarks, this
results in a substantial win over the status quo (~8x benchmark score
for single fields with the changes, ~20x with multiple fields).

The TurboFan JSDefineProperty op is lowered in
JSNativeContextSpecialization, however this required some hacks.
Because private fields are defined as DONT_ENUM when added to the
object, we can't find a suitable transition using the typical data
property (NONE) flags. I've added a mechanism to specify the required
PropertyAttributes for the transition we want to look up.

Details:

New bytecodes:
  - StaKeyedPropertyAsDefine, which is essentially StaKeyedProperty
    but with a different IC builtin (KeyedDefineOwnIC). This is a
    bytecode rather than a flag for the existing StaKeyedProperty in
    order to avoid impacting typical keyed stores in any way due to
    additional branching and testing.

New builtins:
  - StoreOwnIC{TTrampoline|Baseline|_NoFeedback} is now used for
    StaNamedOwnProperty. Unlike the regular StoreIC, this variant will
    no longer look up the property name in the prototype.
    In adddition, this CL changes an assumption that
    StoreNamedOwnProperty can't result in a map transition, as we
    can't rely on the property already being present in the Map due
    to an object literal boilerplate.

    In the context of class features, this replaces the runtime
    function %CreateDataProperty().

  - KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic} is used by the
    new StaKeyedPropertyAsDefine bytecode. This is similar to an
    ordinary KeyedStoreIC, but will not check the prototype for
    setters, and for private fields, will take the slow path if the
    field already exists.

    In the context of class features, this replaces the runtime
    function %AddPrivateField().

TurboFan IR:
  - JSDefineProperty is introduced to represent a situation where we
    need to use "Define" semantics, in particular, it codifies that we
    do not consult the prototype chain, and the semantics relating to
    private fields are implied as well.

R=leszeks@chromium.org, syg@chromium.org, rmcilroy@chromium.org

Bug: v8:9888
Change-Id: Idcc947585c0e612f9e8533aa4e2e0f8f0df8875d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2795831Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#77377}
      713ebae3
  41. 30 Sep, 2021 1 commit
  43. 02 Sep, 2021 1 commit
  45. 27 Aug, 2021 1 commit
    • Leszek Swirski's avatar
      [sparkplug] Clobber accumulator in StaGlobal · 732f394c
      Leszek Swirski authored 
      StaGlobal didn't write the accumulator, but the baseline implementation
assumed that it could preserve the accumulator by taking the return
value of the StoreGlobalIC. This almost always worked, except for
setters on the global object.

Fix this by marking StaGlobal as clobbering the accumulator, same as
StaNamedProperty (StaNamedProperty needs to do this anyway to avoid
inlined setters from needing to create accumulator-preserving frames;
StaGlobal would have needed the same thing if we'd ever inlined setters
for it).

Also, add a new debug scope, EnsureAccumulatorPreservedScope, to the
baseline compiler, which checks if the accumulator value is preserved
across non-accumulator-writing bytecodes. This found a (benign) bug with
ForInPrepare, so fix that too.

Fixed: chromium:1242306
Change-Id: I220b5b1c41010c16ac9f944cbd55d2705c299434
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3122325
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76525}
      732f394c
  47. 12 Aug, 2021 1 commit
  49. 22 Jul, 2021 2 commits
  51. 23 Jun, 2021 1 commit
    • Mihir Shah's avatar
      A jump-table implementation for constant case switch statements · 9711289d
      Mihir Shah authored 
      The change is made since for switch statements with lots of cases,
where each case is a constant integer, the emitted bytecode is still
a series of jumps, when we can instead use a jump table.

If there are 6 or more cases (similar to GCC) of Smi literals, and
if the max Smi case minus the min Smi case is not more than 3 times
the number of cases, we use a jump table up front to handle Smi's,
and then use traditional if-else logic for the rest of the cases.

We then use the jump table in interpreter/bytecode-jump-table to
do the optimization.

This tries to go off issue 9738 in v8's issue tracker. It is not
exactly the same, since that recommends doing the work at JIT-time,
but has similar ideas. It also partially goes off issue 10764.

Bug: v8:9738
Change-Id: Ic805682ee3abf9ce464bb733b427fa0c83a6e10c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904926Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75323}
      9711289d
  53. 14 Jun, 2021 1 commit
  55. 07 Jun, 2021 1 commit
  57. 21 May, 2021 1 commit
  59. 17 May, 2021 1 commit
  61. 11 May, 2021 1 commit
  63. 06 May, 2021 1 commit
    • Fanchen Kong's avatar
      Collect receiver to feedback for prototype.apply · 519c82ce
      Fanchen Kong authored 
      When a function is invoked by prototype.apply, it may undergo following transformation in the JSCallReducer:
	receiver.apply(this, args) ->
	this.receiver(...args) Since the new target (also the receiver of apply()) is not collected to the feedback slot, further speculative optimization on the new target is not available if the new target
is not a heapconstant.

With this CL, the receiver will be collected to the feedback instead of the target if the target is a prototype.apply. It may improve the performance of the following usecase by ~80%.

function reduceArray(func, arr, r) {
    for (var i = 0, len = arr.length; i < len; i++) {
            r = func.apply(null, r, arr[i]);
    }
    return r;
}

var a = 0; for (var i = 0; i < 10000000; i++) {
    a += reduceArray(Math.imul, [5,6,2,3,7,6,8,3,7,9,2,5,], 1);
}
console.log(a);

This CL also improves the runTime score of JetStream2/richards-wasm by ~45% in default, ~60% with --turbo-inline-js-wasm-calls.

Change-Id: I542eb8d3fcb592f4e0993af93ba1af70e89c3982
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639813
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74413}
      519c82ce
  65. 29 Apr, 2021 1 commit
    • Benedikt Meurer's avatar
      [debugger] Remove "Restart frame" feature. · 93f85699
      Benedikt Meurer authored 
      The "Restart frame" feature was implemented as part of LiveEdit and
primarily used to support LiveEdit of active functions, but that was
previously disabled as part of https://crrev.com/c/2846892 because it's
too brittle and causes crashes when using seemingly unrelated features.
The "Restart frame" feature was also available as a context menu item
separately in the DevTools front-end, but that was also already removed
as part of https://crrev.com/c/2854681 earlier. So all uses are gone
now.

This change works by marking Debugger.restartFrame as deprecated and
having it respond with a ServerError all the time. It thus allows us to
remove a whole bunch of machinery that was essentially just put in
various places to support the restart_fp_ magic. In particular the
debugger no longer needs any machine specific builtins now.

Bug: chromium:1195927
Change-Id: I1153ba6b00e979620af57dd9f58aa1c035ec4484
Fixed: chromium:1203606
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2854750Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74276}
      93f85699
  67. 06 Apr, 2021 1 commit
    • Patrick Thier's avatar
      Reland "[sparkplug] OSR Ignition -> Sparkplug" · 064ca18c
      Patrick Thier authored 
      This is a reland of b9c521d0.

Fixes crashes by calling kInstallBaselineCode from BaselineEntry if
needed, i.e. when there is no feedback vector (required a bit of
register rejiggling).
This can happen with cross-realm calls. The OSR arming is stored as
part of the BytecodeArray and therefore shared across realms.

Original change's description:
> [sparkplug] OSR Ignition -> Sparkplug
>
> Add support for OSR to baseline code.
> We compile baseline and perform OSR immediately when the bytecode budget
> interrupt hits.
>
> Drive-by: Clean-up deoptimizer special handling of JumpLoop by using
> the newly introduced GetBaselinePCForNextExecutedBytecode instead of
> GetBaselineEndPCForBytecodeOffset.
>
> Bug: v8:11420
> Change-Id: Ifbea264d4a83a127dd2a11e28626bf2a5e8aca59
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784687
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73677}

Bug: v8:11420
Change-Id: I67325450514ed5a1170b730b1dd59fa6acc6e1d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2800112Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73803}
      064ca18c
  69. 25 Mar, 2021 1 commit