Skip to content

V
V8
Switch branch/tag
  1. 06 Sep, 2019 1 commit
    • Swapnil Gaikwad's avatar
      Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" · ffa9f163
      Swapnil Gaikwad authored 
      This is a reland of 8b89a7c3

Reland after disabling the test getting deadlocked with '--gc_stress' flag.
The CL was reverted because of the 'wasm/grow-shared-memory' test from
the mjsunit test suite deadlocked for the 'gc_stress' variant. This is
the known issue (v8:9221) and the deadlocking test is now disabled (
https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788).


Original change's description:
> Update GetIterator bytecode to load and call object[Symbol.iterator]
>
> The functionality of the GetIterator bytecode introduced previously is
> now extended from loading the @@iterator property to calling the property
> as well. This change basically absorbs the functionality of additional
> two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
> Importantly, this change handles the cases of eager and lazy deoptimization
> in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
> eager deopt of the CallProperty0 bytecode, using the continuation builtins.
> This mechanism can work as a template for the future bytecode that require
> handling such inter-bytecode deopt scenario. The tests evaluating the eager
> and lazy deopt scenarios are also included.
>
> Bug: v8:9489
> Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63528}

Bug: v8:9489,v8:9221
Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Cr-Commit-Position: refs/heads/master@{#63599}
      ffa9f163
  3. 03 Sep, 2019 2 commits
    • Francis McCabe's avatar
      Revert "Update GetIterator bytecode to load and call object[Symbol.iterator]" · af04a51e
      Francis McCabe authored 
      This reverts commit 8b89a7c3.

Reason for revert: GC Stress tests timing out.
See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24272

Original change's description:
> Update GetIterator bytecode to load and call object[Symbol.iterator]
> 
> The functionality of the GetIterator bytecode introduced previously is
> now extended from loading the @@iterator property to calling the property
> as well. This change basically absorbs the functionality of additional
> two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
> Importantly, this change handles the cases of eager and lazy deoptimization
> in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
> eager deopt of the CallProperty0 bytecode, using the continuation builtins.
> This mechanism can work as a template for the future bytecode that require
> handling such inter-bytecode deopt scenario. The tests evaluating the eager
> and lazy deopt scenarios are also included.
> 
> Bug: v8:9489
> Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63528}

TBR=rmcilroy@chromium.org,neis@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com

Change-Id: I9ae475f71275f71f1b9e60b8bf0578e21ce2704b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9489
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783736Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63536}
      af04a51e
    • Swapnil Gaikwad's avatar
      Update GetIterator bytecode to load and call object[Symbol.iterator] · 8b89a7c3
      Swapnil Gaikwad authored 
      The functionality of the GetIterator bytecode introduced previously is
now extended from loading the @@iterator property to calling the property
as well. This change basically absorbs the functionality of additional
two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
Importantly, this change handles the cases of eager and lazy deoptimization
in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
eager deopt of the CallProperty0 bytecode, using the continuation builtins.
This mechanism can work as a template for the future bytecode that require
handling such inter-bytecode deopt scenario. The tests evaluating the eager
and lazy deopt scenarios are also included.

Bug: v8:9489
Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63528}
      8b89a7c3
  5. 20 Aug, 2019 1 commit
    • Jakob Gruber's avatar
      [deoptimizer] Extract frame layout calculation into helper classes · 81642fa6
      Jakob Gruber authored 
      The deoptimizer calculates frame layout based on the translation's
`height` field, together with additional data (e.g.: are we looking at
the topmost frame? what kind of deopt are we in?). The result is the
final deoptimized frame size in bytes, together with a bunch of
intermediate results such as the variable frame size (= without the
fixed-size portion).

In order to consider the deoptimized frame size in optimized stack
checks, we will need to calculate the frame layout during compilation
in addition to what we currently do during deoptimization. This CL
moves in that direction by extracting relevant parts of frame layout
calculation into classes that can be reused by both compiler and
deoptimizer.

These helpers will support both precise and conservative modes; the
deoptimizer will use the precise mode (since it has full information),
while the instruction selector will use the conservative mode.

Bug: v8:9534
Change-Id: I93d6c39f10d251733f4625d3cc161b2010652d02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760825
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63279}
      81642fa6
  7. 27 May, 2019 1 commit
  9. 24 May, 2019 1 commit
  11. 23 May, 2019 5 commits
  13. 22 May, 2019 2 commits
  15. 21 May, 2019 1 commit
  17. 17 May, 2019 1 commit
  19. 16 May, 2019 2 commits
  21. 13 May, 2019 1 commit
  23. 09 May, 2019 2 commits
  25. 29 Apr, 2019 1 commit
  27. 12 Mar, 2019 1 commit
  29. 22 Jan, 2019 1 commit
  31. 17 Jan, 2019 2 commits
  33. 19 Dec, 2018 1 commit
  35. 18 Dec, 2018 1 commit
  37. 14 Dec, 2018 1 commit
  39. 13 Dec, 2018 1 commit
    • Jakob Gruber's avatar
      [builtins] Associate ASM builtins with descriptors · e61d3564
      Jakob Gruber authored 
      Post-stub-to-builtin migration, all explicit connection between
descriptors and their associated ASM code has been lost. This restores
the connection where possible. Builtins without an associated
descriptor are marked with the DummyDescriptor.

Drive-by: alpha-sort the descriptor list.
Drive-by: use Builtins::CallableFor in code factory.

Bug: v8:8562, v8:8553
Change-Id: If1f13bbaf7e42453b3235cc97c58ada91b5fa7b8
Reviewed-on: https://chromium-review.googlesource.com/c/1373552Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58212}
      e61d3564
  41. 22 Nov, 2018 1 commit
  43. 16 Nov, 2018 2 commits
  45. 15 Nov, 2018 4 commits
    • Jakob Gruber's avatar
      [nojit] Store a dedicated InterpreterEntryTrampoline copy on roots · a6e7d781
      Jakob Gruber authored 
      V8 supports a mechanism to generate better profiling information for
ticks in bytecode execution. Usually, these would find the IET but would
not know which JS function is currently being executed. With
--interpreted_frames_native_stack, we create a dedicated copy of the
IET for each JS function, which the profiler can use the infer the
current function.

This mechanism doesn't work when IET is embedded. But JIT-less V8 will
require all builtins to be embedded.

This CL implements a workaround that should keep all configuration
happy: We keep a full copy of IET on the root list for sole purpose of
using it as a template to create copies for profiling later on. The
'real' IET builtin itself can be embedded in a follow-up CL.

Change-Id: Iaf1629708f0e41c3683979245019fbd3e3153c97
Reviewed-on: https://chromium-review.googlesource.com/c/1335700
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57548}
      a6e7d781
    • Jakob Gruber's avatar
      Reland "[builtins] Support embedded builtins in nosnapshot builds" · e1044d10
      Jakob Gruber authored 
      This is a reland of bf2f0a02

Original change's description:
> [builtins] Support embedded builtins in nosnapshot builds
>
> This CL adds support for embedded builtins in nosnap builds by creating
> and setting an 'embedded blob' after builtin generation. Unlike
> snapshot builds, the blob is not embedded into the .text section but
> located on the C++ heap.
>
> This makes nosnap builds more consistent with mksnapshot, and allows us
> to simplify there and in serializer cctests.
>
> Complications arise from the different workflows we need to support:
>
> 1. the standard mksnapshot build process,
> 2. nosnap builds (which reuse the blob created by the first Isolate),
> 2. and tests with various complicated serialization workflows.
>
> To cover all of these cases, this CL introduces two knobs to twiddle:
>
> 1. A 'sticky' embedded blob which overrides compiled-in default
>    embedded blobs at Isolate setup.
> 2. The blob lifecycle can be managed manually or through refcounting.
>
> These are described in more detail in isolate.cc.
>
> Tbr: ulan@chromium.org
> Bug: v8:6666, v8:8350
> Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d
> Reviewed-on: https://chromium-review.googlesource.com/c/1310195
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57523}

Tbr: ulan@chromium.org,yangguo@chromium.org
Bug: v8:6666, v8:8350
Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738
Reviewed-on: https://chromium-review.googlesource.com/c/1337578
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57540}
      e1044d10
    • Jakob Gruber's avatar
      Revert "[builtins] Support embedded builtins in nosnapshot builds" · 856be9c2
      Jakob Gruber authored 
      This reverts commit bf2f0a02.

Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21753

Original change's description:
> [builtins] Support embedded builtins in nosnapshot builds
> 
> This CL adds support for embedded builtins in nosnap builds by creating
> and setting an 'embedded blob' after builtin generation. Unlike
> snapshot builds, the blob is not embedded into the .text section but
> located on the C++ heap.
> 
> This makes nosnap builds more consistent with mksnapshot, and allows us
> to simplify there and in serializer cctests.
> 
> Complications arise from the different workflows we need to support:
> 
> 1. the standard mksnapshot build process,
> 2. nosnap builds (which reuse the blob created by the first Isolate),
> 2. and tests with various complicated serialization workflows.
> 
> To cover all of these cases, this CL introduces two knobs to twiddle:
> 
> 1. A 'sticky' embedded blob which overrides compiled-in default
>    embedded blobs at Isolate setup.
> 2. The blob lifecycle can be managed manually or through refcounting.
> 
> These are described in more detail in isolate.cc.
> 
> Tbr: ulan@chromium.org
> Bug: v8:6666, v8:8350
> Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d
> Reviewed-on: https://chromium-review.googlesource.com/c/1310195
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57523}

TBR=ulan@chromium.org,yangguo@chromium.org,jgruber@chromium.org

Change-Id: I6e35a0cb7186fb50f1012f5c618fb8b48b24a813
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6666, v8:8350
Reviewed-on: https://chromium-review.googlesource.com/c/1337577Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57529}
      856be9c2
    • Jakob Gruber's avatar
      [builtins] Support embedded builtins in nosnapshot builds · bf2f0a02
      Jakob Gruber authored 
      This CL adds support for embedded builtins in nosnap builds by creating
and setting an 'embedded blob' after builtin generation. Unlike
snapshot builds, the blob is not embedded into the .text section but
located on the C++ heap.

This makes nosnap builds more consistent with mksnapshot, and allows us
to simplify there and in serializer cctests.

Complications arise from the different workflows we need to support:

1. the standard mksnapshot build process,
2. nosnap builds (which reuse the blob created by the first Isolate),
2. and tests with various complicated serialization workflows.

To cover all of these cases, this CL introduces two knobs to twiddle:

1. A 'sticky' embedded blob which overrides compiled-in default
   embedded blobs at Isolate setup.
2. The blob lifecycle can be managed manually or through refcounting.

These are described in more detail in isolate.cc.

Tbr: ulan@chromium.org
Bug: v8:6666, v8:8350
Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d
Reviewed-on: https://chromium-review.googlesource.com/c/1310195Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57523}
      bf2f0a02
  47. 13 Nov, 2018 1 commit
  49. 12 Nov, 2018 1 commit
  51. 07 Nov, 2018 1 commit
  53. 05 Nov, 2018 1 commit
    • Tobias Tebbi's avatar
      [torque] cleanup generics and scopes · 06c8ce59
      Tobias Tebbi authored 
      - Name lookup in module scopes has namespace semantics now: All
  overloads from all parent modules are combined before overload
  resolution.
- Allow overloads of different callables: runtime-functions,
  macros, builtins, and generics.
- The duplication between the DeclarationVisitor and the
  ImplementationVisitor is removed: The DeclarationVisitor creates
  declarables for everything except for implicit generic specializations.
  The ImplementationVisitor iterates over declarables.
  The DeclarationVisitor only looks at the header of declarations, not
  at the body.
- Modules become Declarable's, which will enable them to be nested.
- Modules replace the existing Scope chain mechanism, which will make it
  easier to inline macros.
- The DeclarationVisitor and Declarations become stateless. All state is
  moved to contextual variables and the GlobalContext.
- Implicit specializations are created directly from the
  ImplementationVisitor. This will enable template parameter inference.
- As a consequence, the list of all builtins is only available after the
  ImplementationVisitor has run. Thus GenerateBuiltinDefinitions has to
  move to the ImplementationVisitor. Also, this makes it necessary to
  resolve the link from function pointer types to example builtins only
  at this point.


Bug: v8:7793
Change-Id: I61cef2fd3e954ab148c252974344a6e38ee2d01d
Reviewed-on: https://chromium-review.googlesource.com/c/1304294
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57231}
      06c8ce59