Skip to content

V
V8
Switch branch/tag
  1. 07 Jul, 2022 1 commit
  3. 05 May, 2022 1 commit
  5. 11 May, 2021 1 commit
  7. 18 Jan, 2021 1 commit
  9. 14 Dec, 2020 1 commit
    • Nico Hartmann's avatar
      Revert "[TurboFan] Move SFI and BytecodeArray to kNeverSerialized" · ff606a06
      Nico Hartmann authored 
      This reverts commit 8ffbf0d2.

Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=1158322

Original change's description:
> [TurboFan] Move SFI and BytecodeArray to kNeverSerialized
>
> This CL moves SharedFunctionInfo and BytecodeArray to the
> kNeverSerialized classes, making them directly accessible from the
> background thread.
>
> To resolve the dependence on HeapNumber and BigInt objects stored in
> the BytecodeArray's constant pool, this CL introduces a new
> ObjectDataKind::kPossiblyBackgroundSerializedHeapObject, which allows
> for objects to be serialized lazily from the background thread where
> we know that this is safe (e.g. because they are constant). BigInt and
> HeapNumber are the first members of this new group of objects.
>
> Bug: v8:7790
> Change-Id: I1d962d1cb7c36cc3f5baeb9603d5298f32af3363
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567705
> Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71716}

TBR=neis@chromium.org,nicohartmann@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:7790
Change-Id: Ice35d7c1c4d7e96be887a0aa26fbfa69db627022
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589734Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71738}
      ff606a06
  11. 11 Dec, 2020 1 commit
    • Nico Hartmann's avatar
      [TurboFan] Move SFI and BytecodeArray to kNeverSerialized · 8ffbf0d2
      Nico Hartmann authored 
      This CL moves SharedFunctionInfo and BytecodeArray to the
kNeverSerialized classes, making them directly accessible from the
background thread.

To resolve the dependence on HeapNumber and BigInt objects stored in
the BytecodeArray's constant pool, this CL introduces a new
ObjectDataKind::kPossiblyBackgroundSerializedHeapObject, which allows
for objects to be serialized lazily from the background thread where
we know that this is safe (e.g. because they are constant). BigInt and
HeapNumber are the first members of this new group of objects.

Bug: v8:7790
Change-Id: I1d962d1cb7c36cc3f5baeb9603d5298f32af3363
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567705Reviewed-by: 's avatarGeorg Neis (ooo until January 5) <neis@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71716}
      8ffbf0d2
  13. 28 Sep, 2020 1 commit
  15. 20 Jul, 2020 1 commit
  17. 10 Jul, 2020 1 commit
  19. 17 Mar, 2020 1 commit
  21. 16 Mar, 2020 1 commit
  23. 13 Mar, 2020 1 commit
  25. 28 Aug, 2019 1 commit
  27. 09 Jul, 2019 1 commit
  29. 23 May, 2019 1 commit
  31. 21 May, 2019 1 commit
  33. 07 Mar, 2019 1 commit
  35. 06 Mar, 2019 1 commit
  37. 24 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] ReceiverOrNullOrUndefined feedback for JSEqual. · f19c4a59
      Benedikt Meurer authored 
      This changes the ReceiverOrOddball feedback on JSStrictEqual to
ReceiverOrNullOrUndefined feedback, which can also safely be
consumed by JSEqual (we cannot generally accept any oddball here
since booleans trigger implicit conversions, unfortunately).
Thus we replace the previously introduced CheckReceiverOrOddball
with CheckReceiverOrNullOrUndefined, and drop CheckOddball, since
we will no longer collect Oddball feedback separately.

TurboFan will then turn a JSEqual[ReceiverOrNullOrUndefined] into
a sequence like this:

```
left = CheckReceiverOrNullOrUndefined(left);
right = CheckReceiverOrNullOrUndefined(right);
result = if ObjectIsUndetectable(left) then
           ObjectIsUndetectable(right)
         else
           ReferenceEqual(left, right);
```

This significantly improves the peak performance of abstract equality
with Receiver, Null or Undefined inputs. On the test case outlined in
http://crbug.com/v8/8356 we go from

  naive: 2946 ms.
  tenary: 2134 ms.

to

  naive: 2230 ms.
  tenary: 2250 ms.

which corresponds to a 25% improvement on the abstract equality case.
For regular code this will probably yield more performance, since we
get rid of the JSEqual operator, which might have arbitrary side
effects and thus blocks all kinds of TurboFan optimizations. The
JSStrictEqual case is slightly slower now, since it has to rule out
booleans as well (even though that's not strictly necessary, but
consistency is key here).

This way developers can safely use `a == b` instead of doing a dance
like `a == null ? b == null : a === b` (which is what dart2js does
right now) when both `a` and `b` are known to be Receiver, Null or
Undefined. The abstract equality is not only faster to parse than
the tenary, but also generates a shorter bytecode sequence. In the
test case referenced in http://crbug.com/v8/8356 the bytecode for
`naive` is

```
StackCheck
Ldar a1
TestEqual a0, [0]
JumpIfFalse [5]
LdaSmi [1]
Return
LdaSmi [2]
Return
```

which is 14 bytes, whereas the `tenary` function generates

```
StackCheck
Ldar a0
TestUndetectable
JumpIfFalse [7]
Ldar a1
TestUndetectable
Jump [7]
Ldar a1
TestEqualStrict a0, [0]
JumpIfToBooleanFalse [5]
LdaSmi [1]
Return
LdaSmi [2]
Return
```

which is 24 bytes. So the `naive` version is 40% smaller and requires
fewer bytecode dispatches.

Bug: chromium:898455, v8:8356
Change-Id: If3961b2518b4438700706b3bd6071d546305e233
Reviewed-on: https://chromium-review.googlesource.com/c/1297315Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56948}
      f19c4a59
  39. 18 Oct, 2018 1 commit
  41. 18 Sep, 2018 2 commits
    • Benedikt Meurer's avatar
      [es2015] Change JSArrayBufferView::byte_length/byte_offset to uintptr_t. · 5cfe1a6b
      Benedikt Meurer authored 
      This is the next step to support large array buffers. On 64-bit archs
the full safe integer range is available (up to 2^53-1 bytes in theory).
On 32-bit platforms the full Unsigned31 range is allowed, so that we can
continue to use CheckBounds for typed arrays and data views in the
optimizing compiler (it's generally unlikely that the kernel will give
you more than 1GiB of contiguous memory anyways).

Drive-by-fix: This introduces proper chokepoints for the byte_offset
and byte_length accesses in the CSA code, and also does some renaming
for consistency.

Bug: v8:4153, v8:7881, v8:8171
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I92a767638532ca9f86084398ce72556c5180cc6e
Reviewed-on: https://chromium-review.googlesource.com/1228377Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56008}
      5cfe1a6b
    • Georg Neis's avatar
      [turbofan] Get rid of HeapObjectType-related heap reads. · 253c2469
      Georg Neis authored 
      This removes the last unconditional read accesses to the heap, but
required a significant refactoring.

- Remove HeapObjectRef::type().
- Change HeapObjectData::Is* testers to look at the instance type
  in HeapObjectData::map().

- Remove ObjectRef::oddball_type()
- Add MapRef::oddball_type()
- Add MapRef::is_undetectable().
- Add MapRef::is_callable().

- Remove JSHeapBroker::HeapObjectTypeFromMap()
- Remove Type::For(JSHeapBroker*, Handle<Map>)
- Add BitsetType::Lub(MapRef).
- Add Type::For(MapRef).
- Add Type::For(HeapObjectType).

- Add HeapObjectRef::GetHeapObjectType(). THIS IS TEMPORARY.

As the last item suggests, I couldn't actually remove the
HeapObjectType class yet. See the explanation in the code.

Bug: v8:7790
Change-Id: I508e4bd5337277b0050f2204392fc36f41032fe9
Reviewed-on: https://chromium-review.googlesource.com/1228033Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55994}
      253c2469
  43. 17 Jul, 2018 1 commit
  45. 20 Jun, 2018 1 commit
  47. 18 Jun, 2018 1 commit
  49. 15 Jun, 2018 1 commit
  51. 25 May, 2018 1 commit
  53. 07 May, 2018 2 commits
  55. 04 May, 2018 1 commit
    • Ben L. Titzer's avatar
      [compiler] Factor MachineGraph out from JSGraph · bc218a2e
      Ben L. Titzer authored 
      This CL factors the parts of the JSGraph that only depend on the
machine part of JSGraph into a separate base class, MachineGraph.
This helps separate the two layers and also allows the MachineGraph
to be constructed without an Isolate, which is needed for fully
asynchronous compilation, a goal for WASM.

R=mstarzinger@chromium.org
CC=jarin@chromium.org, mvstanton@chromium.org

BUG=v8:7721

Change-Id: Ie8bc3de40159332645dcb3cadcee581e1bf9830a
Reviewed-on: https://chromium-review.googlesource.com/1043746Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52990}
      bc218a2e
  57. 25 Apr, 2018 1 commit
    • Andreas Haas's avatar
      Reland: [refactoring] Remove the isolate from signatures of ExternalReferences · 2a3c2c73
      Andreas Haas authored 
      I missed one required change which was hidden behind an #if. The fix is in
the diff between Patch 1 and Patch 3.

Original message:
In this CL I remove the isolate from signatures of ExternalReference
accessor functions where the isolate is not used. The uses of the
isolate were already removed in previous CLs.

Changes:
* I split the ExternalReference list in external-reference.h into
those which need the isolate for initialization and those which do not.

* I removed the public constructors and replaced them by
  ExternalReference::Create(). The reason is to separate external
  creation more clearly from internal creation, because externally
  created ExternalReferences sometimes need redirection, whereas
  internally created ExternalReferences are just stored as they are.
  In addition, by removing the isolate from the signature of the
  public constructors, they suddenly exactly matched the interal
  constructor.

* Replace all uses of the public constructors with
  ExternalReference::Create().

* Remove the isolate from all call sites where necessary.


This is a step towards making WebAssembly compilation independent of
the isolate.

R=mstarzinger@chromium.org

Bug: v8:7570
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I750c162f5d58ed32e866722b0db920f8b9bd8057
Reviewed-on: https://chromium-review.googlesource.com/1026673Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52777}
      2a3c2c73
  59. 24 Apr, 2018 2 commits
    • Andreas Haas's avatar
      Revert "[refactoring] Remove the isolate from signatures of ExternalReferences" · 7bfed2ad
      Andreas Haas authored 
      This reverts commit 44ea425a.

Reason for revert: https://ci.chromium.org/buildbot/client.v8.ports/V8%20Arm%20-%20debug%20builder/13575

Original change's description:
> [refactoring] Remove the isolate from signatures of ExternalReferences
> 
> In this CL I remove the isolate from signatures of ExternalReference
> accessor functions where the isolate is not used. The uses of the
> isolate were already removed in previous CLs.
> 
> Changes:
> * I split the ExternalReference list in external-reference.h into
> those which need the isolate for initialization and those which do not.
> 
> * I removed the public constructors and replaced them by
>   ExternalReference::Create(). The reason is to separate external
>   creation more clearly from internal creation, because externally
>   created ExternalReferences sometimes need redirection, whereas
>   internally created ExternalReferences are just stored as they are.
>   In addition, by removing the isolate from the signature of the
>   public constructors, they suddenly exactly matched the interal
>   constructor.
> 
> * Replace all uses of the public constructors with
>   ExternalReference::Create().
> 
> * Remove the isolate from all call sites where necessary.
> 
> 
> This is a step towards making WebAssembly compilation independent of
> the isolate.
> 
> Bug: v8:7570
> R=​mstarzinger@chromium.org
> 
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da
> Reviewed-on: https://chromium-review.googlesource.com/1018982
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52768}

TBR=mstarzinger@chromium.org,ahaas@chromium.org

Change-Id: I7c0d8d420f815cede23d550dee8942ac4d7791cc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7570
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1026570Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52769}
      7bfed2ad
    • Andreas Haas's avatar
      [refactoring] Remove the isolate from signatures of ExternalReferences · 44ea425a
      Andreas Haas authored 
      In this CL I remove the isolate from signatures of ExternalReference
accessor functions where the isolate is not used. The uses of the
isolate were already removed in previous CLs.

Changes:
* I split the ExternalReference list in external-reference.h into
those which need the isolate for initialization and those which do not.

* I removed the public constructors and replaced them by
  ExternalReference::Create(). The reason is to separate external
  creation more clearly from internal creation, because externally
  created ExternalReferences sometimes need redirection, whereas
  internally created ExternalReferences are just stored as they are.
  In addition, by removing the isolate from the signature of the
  public constructors, they suddenly exactly matched the interal
  constructor.

* Replace all uses of the public constructors with
  ExternalReference::Create().

* Remove the isolate from all call sites where necessary.


This is a step towards making WebAssembly compilation independent of
the isolate.

Bug: v8:7570
R=mstarzinger@chromium.org

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da
Reviewed-on: https://chromium-review.googlesource.com/1018982
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52768}
      44ea425a
  61. 04 Jan, 2018 2 commits
  63. 03 Jan, 2018 1 commit
  65. 16 Nov, 2017 1 commit
    • Tobias Tebbi's avatar
      Reland^6 "[turbofan] eagerly prune None types and deadness from the graph" · 19ac10e5
      Tobias Tebbi authored 
      Reland of https://chromium-review.googlesource.com/c/v8/v8/+/727893
The crashes should be fixed by https://chromium-review.googlesource.com/c/v8/v8/+/763531

Original change's description:
> Revert "Reland^5 "[turbofan] eagerly prune None types and deadness from the graph""
> 
> This reverts commit ac0661b3.
> 
> Reason for revert: Clusterfuzz unhappy: chromium:783019 chromium:783035
> 
> Original change's description:
> > Reland^5 "[turbofan] eagerly prune None types and deadness from the graph"
> >
> > This gives up on earlier attempts to interpret DeadValue as a signal of
> > unreachable code. This does not work because free-floating dead value
> > nodes, and even pure branch nodes that use them, can get scheduled so
> > early that they get reachable. Instead, we now eagerly remove branches
> > that use DeadValue in DeadCodeElimination and replace DeadValue inputs
> > to value phi nodes with dummy values.
> >
> > Reland of https://chromium-review.googlesource.com/715716
> >
> > Bug: chromium:741225 chromium:776256
> > Change-Id: I251efd507c967d4a8882ad8fd2fd96c4185781fe
> > Reviewed-on: https://chromium-review.googlesource.com/727893
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#49188}
> 
> TBR=jarin@chromium.org,tebbi@chromium.org
> 
> Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035
> Change-Id: I6a8fa3a08ce2824a858ae01817688e63ed1f442e
> Reviewed-on: https://chromium-review.googlesource.com/758770
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49262}

TBR=jarin@chromium.org,tebbi@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035
Change-Id: I6c02b4beb02997ec34015ed2f6791a93c70f5e36
Reviewed-on: https://chromium-review.googlesource.com/772150
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49429}
      19ac10e5
  67. 14 Nov, 2017 1 commit
    • Michael Stanton's avatar
      Revert "[TurboFan] Diagnostic code to track down bug in representation selection" · ebe6d7a9
      Michael Stanton authored 
      This reverts commit f010b28f.

Reason for revert: Introduces a clusterfuzz issue and CAnary crash

Original change's description:
> [TurboFan] Diagnostic code to track down bug in representation selection
> 
> We need to characterize the types of dead (IrOpcode::kDead) nodes
> introduced in compilation phases prior to representation selection.
> Normally, a dead node isn't expected at the start of this phase. The
> question is, which phase introduced the dead node and failed to
> deal with it properly?
> 
> Bug: chromium:780658
> Change-Id: Ief5b45480bb7d704a2d09dafd60b5d389e0fd42e
> Reviewed-on: https://chromium-review.googlesource.com/765968
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49328}

TBR=mvstanton@chromium.org,mstarzinger@chromium.org

Change-Id: I5d628eb1de630ce4a353b6ef0f80fd74ad740f17
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:780658
Reviewed-on: https://chromium-review.googlesource.com/768747Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49347}
      ebe6d7a9
  69. 13 Nov, 2017 1 commit
  71. 09 Nov, 2017 1 commit
    • Tobias Tebbi's avatar
      Revert "Reland^5 "[turbofan] eagerly prune None types and deadness from the graph"" · c899637d
      Tobias Tebbi authored 
      This reverts commit ac0661b3.

Reason for revert: Clusterfuzz unhappy: chromium:783019 chromium:783035

Original change's description:
> Reland^5 "[turbofan] eagerly prune None types and deadness from the graph"
>
> This gives up on earlier attempts to interpret DeadValue as a signal of
> unreachable code. This does not work because free-floating dead value
> nodes, and even pure branch nodes that use them, can get scheduled so
> early that they get reachable. Instead, we now eagerly remove branches
> that use DeadValue in DeadCodeElimination and replace DeadValue inputs
> to value phi nodes with dummy values.
>
> Reland of https://chromium-review.googlesource.com/715716
>
> Bug: chromium:741225 chromium:776256
> Change-Id: I251efd507c967d4a8882ad8fd2fd96c4185781fe
> Reviewed-on: https://chromium-review.googlesource.com/727893
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49188}

TBR=jarin@chromium.org,tebbi@chromium.org

Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035
Change-Id: I6a8fa3a08ce2824a858ae01817688e63ed1f442e
Reviewed-on: https://chromium-review.googlesource.com/758770Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49262}
      c899637d