Skip to content

V
V8
Switch branch/tag
  1. 06 Mar, 2018 1 commit
  3. 02 Mar, 2018 4 commits
    • Georg Neis's avatar
      [ic] Introduce new IC for storing into array literals. · 2e2860f7
      Georg Neis authored 
      ... and use it in the implementation of array literal spreads,
replacing calls to %AppendElement.

Array spreads in destructuring will be taken care of in a separate CL.

Bug: v8:5940, v8:7446
Change-Id: Idec52398902a7fd3c1244852cf73246f142404f0
Reviewed-on: https://chromium-review.googlesource.com/915364
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51709}
      2e2860f7
    • Georg Neis's avatar
      Reland "[parsing] inline ArrayLiteral creation for spread calls" · 82345e9f
      Georg Neis authored 
      This reverts commit f48e7349.

Reason for revert: innocent!!

Original change's description:
> Revert "[parsing] inline ArrayLiteral creation for spread calls"
> 
> This reverts commit 93fc3841.
> 
> Reason for revert: may break node.js integration
> 
> Original change's description:
> > [parsing] inline ArrayLiteral creation for spread calls
> > 
> > Instead of using runtime calls to generate the Array Literal passed to
> > %reflect_call / %reflect_construct, we create an ArrayLiteral from the
> > list of arguments, and perform spreads using the interpreter mechanism for
> > spreading in ArrayLiterals (thus, the spreading becomes inline). This
> > array literal is still passed to %reflect_call / %reflect_construct as
> > before.
> > 
> > This cuts the runtime for bench-spread-call.js -> testSpread roughly in
> > half, and will likely improve further once
> > https://chromium-review.googlesource.com/c/v8/v8/+/915364 has landed.
> > 
> > BUG=v8:7446
> > R=​neis@chromium.org, adamk@chromium.org
> > 
> > Change-Id: I74a6acd3a60aad422e4ac575275c7b567659d8ad
> > Reviewed-on: https://chromium-review.googlesource.com/939587
> > Commit-Queue: Georg Neis <neis@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#51678}
> 
> TBR=adamk@chromium.org,neis@chromium.org,caitp@igalia.com,bmeurer@chromium.org
> 
> Change-Id: I4730077591bce0e5e7b2ce7d59678e8b7135cc08
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:7446
> Reviewed-on: https://chromium-review.googlesource.com/945769
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51682}

TBR=adamk@chromium.org,neis@chromium.org,sigurds@chromium.org,caitp@igalia.com,bmeurer@chromium.org

Change-Id: I977513bea06a4f3fba03fa4a89270298475422e2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7446
Reviewed-on: https://chromium-review.googlesource.com/945808Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51686}
      82345e9f
    • Sigurd Schneider's avatar
      Revert "[parsing] inline ArrayLiteral creation for spread calls" · f48e7349
      Sigurd Schneider authored 
      This reverts commit 93fc3841.

Reason for revert: may break node.js integration

Original change's description:
> [parsing] inline ArrayLiteral creation for spread calls
> 
> Instead of using runtime calls to generate the Array Literal passed to
> %reflect_call / %reflect_construct, we create an ArrayLiteral from the
> list of arguments, and perform spreads using the interpreter mechanism for
> spreading in ArrayLiterals (thus, the spreading becomes inline). This
> array literal is still passed to %reflect_call / %reflect_construct as
> before.
> 
> This cuts the runtime for bench-spread-call.js -> testSpread roughly in
> half, and will likely improve further once
> https://chromium-review.googlesource.com/c/v8/v8/+/915364 has landed.
> 
> BUG=v8:7446
> R=​neis@chromium.org, adamk@chromium.org
> 
> Change-Id: I74a6acd3a60aad422e4ac575275c7b567659d8ad
> Reviewed-on: https://chromium-review.googlesource.com/939587
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51678}

TBR=adamk@chromium.org,neis@chromium.org,caitp@igalia.com,bmeurer@chromium.org

Change-Id: I4730077591bce0e5e7b2ce7d59678e8b7135cc08
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7446
Reviewed-on: https://chromium-review.googlesource.com/945769Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51682}
      f48e7349
    • Caitlin Potter's avatar
      [parsing] inline ArrayLiteral creation for spread calls · 93fc3841
      Caitlin Potter authored 
      Instead of using runtime calls to generate the Array Literal passed to
%reflect_call / %reflect_construct, we create an ArrayLiteral from the
list of arguments, and perform spreads using the interpreter mechanism for
spreading in ArrayLiterals (thus, the spreading becomes inline). This
array literal is still passed to %reflect_call / %reflect_construct as
before.

This cuts the runtime for bench-spread-call.js -> testSpread roughly in
half, and will likely improve further once
https://chromium-review.googlesource.com/c/v8/v8/+/915364 has landed.

BUG=v8:7446
R=neis@chromium.org, adamk@chromium.org

Change-Id: I74a6acd3a60aad422e4ac575275c7b567659d8ad
Reviewed-on: https://chromium-review.googlesource.com/939587
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51678}
      93fc3841
  5. 01 Mar, 2018 4 commits
  7. 26 Feb, 2018 1 commit
  9. 21 Feb, 2018 5 commits
  11. 20 Feb, 2018 1 commit
  13. 19 Feb, 2018 1 commit
  15. 16 Feb, 2018 1 commit
  17. 15 Feb, 2018 3 commits
  19. 14 Feb, 2018 2 commits
  21. 13 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Refactor the promise resolution and rejection logic. · c0412961
      Benedikt Meurer authored 
      This introduces dedicated builtins

  - FulfillPromise,
  - RejectPromise, and
  - ResolvePromise,

which perform the corresponding operations from the language
specification, and removes the redundant entry points and the
excessive inlining of these operations into other builtins. We
also add the same logic on the C++ side, so that we don't need
to go into JavaScript land when resolving/rejecting from the
API.

The C++ side has a complete implementation, including full support
for the debugger and the current PromiseHook machinery. This is to
avoid constantly crossing the boundary for those cases, and to also
simplify the CSA side (and soon the TurboFan side), where we only
do the fast-path and bail out to the runtime for the general handling.

On top of this we introduce %_RejectPromise and %_ResolvePromise,
which are entry points used by the bytecode and parser desugarings
for async functions, and also used by the V8 Extras API. Thanks to
this we can uniformly optimize these in TurboFan, where we have
corresponding operators JSRejectPromise and JSResolvePromise, which
currently just call into the builtins, but middle-term can be further
optimized, i.e. to skip the "then" lookup for JSResolvePromise when
we know something about the resolution.

In TurboFan we can also already inline the default PromiseCapability
[[Reject]] and [[Resolve]] functions, although this is not as effective
as it can be right now, until we have inlining support for the Promise
constructor (being worked on by petermarshall@ right now) and/or SFI
based CALL_IC feedback.

Overall this change is meant as a refactoring without significant
performance impact anywhere; it seems to improve performance of
simple async functions a bit, but otherwise is neutral.

Bug: v8:7253
Change-Id: Id0b979f9b2843560e38cd8df4b02627dad4b6d8c
Reviewed-on: https://chromium-review.googlesource.com/911632Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51260}
      c0412961
  23. 12 Feb, 2018 2 commits
    • Adam Klein's avatar
      [parser] Remove pretenuring of closures assigned to properties · 20e346bd
      Adam Klein authored 
      This pretenuring was added in https://codereview.chromium.org/5220007,
back when it was necessary in order to allow use of the closure
as a "constant function" property. This should no longer be the case,
and the pretenuring causes some unfortunate downstream effects.

This patch removes the parser's setting of this bit. If it doesn't
cause regressions on the perf bots, followup CLs will remove the
rest of the support for this feature.

Bug: v8:7442
Change-Id: I27c43dd4293ce5de921be6c78571e712778d138a
Reviewed-on: https://chromium-review.googlesource.com/914610Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51254}
      20e346bd
    • Caitlin Potter's avatar
      [esnext] implement spec change to TaggedTemplate callsite caching · d3ca0d00
      Caitlin Potter authored 
      Implements the change outlined in https://github.com/tc39/ecma262/pull/890,
which has been ratified and pulled into the specification. In particular,
template callsite objects are no longer kept in a global, eternal Map, but
are instead associated with their callsite, which can be collected. This
prevents a memory leak incurred by TaggedTemplate calls.

Changes, summarized:

    - Remove the TemplateMap and TemplateMapShape objects, instead caching
      template objects in the feedback vector.
    - Remove the `hash` member of TemplateObjectDescriptor, and the Equals
      method (used by TemplateMap)
    - Add a new FeedbackSlotKind (kTemplateObject), which behaves similarly
      to FeedbackSlotKind::kLiteral, but prevents eval caching. This ensures
      that a new feedback vector is always created for eval() containing tagged
      templates, even when the CompilationCache is used.
    - GetTemplateObject bytecode now takes a feedback index, and only calls
      into the runtime if the feedback is Smi::kZero (uninitialized).

BUG=v8:3230, v8:2891
R=littledan@chromium.org, yangguo@chromium.org, bmeurer@chromium.org,
rmcilroy@chromium.org

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I7827bc148d3d93e2b056ebf63dd624da196ad423
Reviewed-on: https://chromium-review.googlesource.com/624564
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51248}
      d3ca0d00
  25. 08 Feb, 2018 1 commit
  27. 07 Feb, 2018 2 commits
  29. 06 Feb, 2018 1 commit
  31. 03 Feb, 2018 1 commit
  33. 02 Feb, 2018 1 commit
  35. 01 Feb, 2018 1 commit
  37. 29 Jan, 2018 2 commits
  39. 24 Jan, 2018 1 commit
  41. 17 Jan, 2018 3 commits
  43. 12 Jan, 2018 1 commit