Skip to content

V
V8
Switch branch/tag
  1. 20 Feb, 2018 2 commits
  3. 19 Feb, 2018 2 commits
  5. 17 Feb, 2018 2 commits
  7. 16 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [async-await] Eliminate throwaway promise in async functions. · a840f1f8
      Benedikt Meurer authored 
      The ES2017 specification contains a so-called "throwaway" promise that
is used to specify the behavior of await in terms of PerformPromiseThen,
but it's actually not necessary and never exposed to user code. In
addition to that, hooking up the promise in await required a context (to
refer to the generator object) and two closures for the reject/fulfill
handling, which would resume the generator corresponding to the async
function. That meant, we had to allocate 4 additional objects for every
await.

Instead of using a JSPromise plus the callbacks, this CL adds logic to
allow PromiseReaction and PromiseReactionJobTask to carry arbitrary
payloads and Code handlers. We use this for await to avoid the
additional 4 objects mentioned above, and instead just have simple Code
handlers that resume the generator (for the async function), either by
throwing (in case of a rejection) or by resuming normally (in case of
fulfillment).

For this to work properly the JSGeneratorObject has to have a link to
the outer promise returned by the async function, so that the catch
prediction can still figure out what to do in case of promise rejection.
This is done by adding a new generator_outer_promise_symbol when the
debugger is active, which refers from the generator to the outer
promise.

With this change the doxbee-async-es2017-native test goes from around
100.54ms to around 82.45ms, which corresponds to a ~18% reduction in
execution time.

Bug: v8:7253
Change-Id: Iae25b3300bac351c3417be5ae687eff469b0e61f
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/924069Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51334}
      a840f1f8
  9. 15 Feb, 2018 2 commits
    • Georg Neis's avatar
      Reland "[ic] EmitElementStore: don't miss when hitting new space limit." · a50bc8ac
      Georg Neis authored 
      This is a reland of af677f29, fixing
an issue with negative indices.

Original change's description:
> [ic] EmitElementStore: don't miss when hitting new space limit.
>
> CSA::EmitElementStore used to bail out (IC miss) via
> CSA::CheckForCapacityGrow when the capacity hits the new space
> limit, causing the store IC to go megamorphic in my example (see
> referenced bug). With this CL, we do what TF'ed code does already:
> call into Runtime::kGrowArrayElements (in this situation), thus
> staying monomorphic.
>
> Here's a contrived test case:
>
> ////////////////////////
> let x = [];
>
> function bar() {
>   for (let i = 0; i < 50000; ++i) x[i] = i;
> }
>
> function foo() {
>   for (let i = x.length; i < 100e6; ++i) x[i] = i;
> }
>
> bar();
> foo();
> ////////////////////////
>
> This took about 4s on my machine, now it takes 3s.
>
> Bug: v8:7447
> Change-Id: I7f268fc55835f363d250613ce0357444a663051c
> Reviewed-on: https://chromium-review.googlesource.com/918723
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51297}

Bug: v8:7447, chromium:812451
Change-Id: I345b5e5b2437c4f50e42bbd87947630f24cd95eb
Reviewed-on: https://chromium-review.googlesource.com/921201
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51311}
      a50bc8ac
    • Toon Verwaest's avatar
      Remove %_ClassOf and SharedFunctionInfo::instance_class_name · 313e33a7
      Toon Verwaest authored 
      instance_class_name takes up space unnecessarily, and %_ClassOf and
class_name implement [[Class]] which isn't part of ES2015+ anymore.

Bug: 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3a73f732ad83a616817fde9992f4e4d584638fa8
Reviewed-on: https://chromium-review.googlesource.com/776683Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51309}
      313e33a7
  11. 13 Feb, 2018 2 commits
    • Sigurd Schneider's avatar
      Reland "[cleanup] Harden the SubString CSA/Runtime implementations." · bb282636
      Sigurd Schneider authored 
      This is a reland of 6d5b54df82e27a82811a836dcdbbfe26829f0e6d
Original change's description:
> [cleanup] Harden the SubString CSA/Runtime implementations.
>
> Remove the self-healing for invalid parameters in the
> CodeStubAssembler::SubString helper and the %SubString runtime function,
> which is used as a fallback for the CodeStubAssembler implementation.
> All call sites must do appropriate parameter validation anyways now that
> the self-hosted JavaScript builtins using these helpers are gone, and we
> have proper contracts with the uses.
>
> Also remove the context parameter from the CodeStubAssembler::SubString
> method, which is unnecessary, since this can no longer throw an
> exception.
>
> Bug: v8:5269, v8:6936, v8:7109, v8:7137
> Change-Id: I19d93bad5f41faa0561c4561a48f78fcba99a549
> Reviewed-on: https://chromium-review.googlesource.com/795720
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49702}

Bug: v8:5269, v8:6936, v8:7109, v8:7137
Change-Id: I5e84998a2dd3990d7981505b401ffc770e0b7ac5
Reviewed-on: https://chromium-review.googlesource.com/913130Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51265}
      bb282636
    • 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
  13. 12 Feb, 2018 1 commit
    • 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
  15. 08 Feb, 2018 3 commits
  17. 07 Feb, 2018 5 commits
  19. 05 Feb, 2018 1 commit
  21. 02 Feb, 2018 1 commit
  23. 01 Feb, 2018 1 commit
  25. 31 Jan, 2018 4 commits
    • Benedikt Meurer's avatar
      [builtins] Squeeze JSPromise::result and JSPromise::reactions into a single field. · 8a677a28
      Benedikt Meurer authored 
      A given JSPromise can either be in pending state, and accumulates
reactions, or in settled state, where all reactions are scheduled
as microtasks, and it carries a result. So we can use a single field
on the JSPromise instance to hold both the result and the reactions
and that field is interpreted differently depending on the status of
the JSPromise.

Bug: v8:7253
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I19a7d499c88f452f0d35979ab95deb110021cde9
Reviewed-on: https://chromium-review.googlesource.com/895528Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51004}
      8a677a28
    • Mike Stanton's avatar
      [Feedback Vector] Coalesce Nexii to Feedback Nexus. · 291dc3cd
      Mike Stanton authored 
      The FeedbackNexus classes initially were one-to-one with IC classes,
but over time this got out of date. We also found Nexus' useful, so
we made more classes even for cases that weren't ICs.

The inheritence and polymorphism became confusing and led to
duplication. Better, to just talk about a (single) FeedbackNexus.

Bug: v8:7344
Change-Id: I509dc9657895d56c3859de6e6589695cdff9e73e
Reviewed-on: https://chromium-review.googlesource.com/890452
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarFranziska Hinkelmann <franzih@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50997}
      291dc3cd
    • Benedikt Meurer's avatar
      [builtins] Refactor promises to reduce GC overhead. · 8e7737cb
      Benedikt Meurer authored 
      This implements the ideas outlined in the section "Microtask queue"
of the exploration document "Promise and async/await performance" (at
https://goo.gl/WHRar2), except that the microtask queue stays a linear
FixedArray for now, to avoid running into trouble with the parallel
scavenger. This way we can already save a significant amount of
allocations, thereby reducing the GC frequency quite a bit.

All items on the microtask queue are now proper structs that subclass
Microtask, i.e. we also wrap JSFunction and MicrotaskCallback jobs
into structs. We also consistently remember the context for every
microtask (except for MicrotaskCallback where we don't have a
context), and execute it later in exactly that context (as required
by the spec anyways for the Promise related jobs). Particularly
interesting is the PromiseReactionJobTask and its subclasses, since
they are designed to have the same size as the PromiseReaction. When
we resolve a JSPromise we just take the existing PromiseReaction
instances and morph them into PromiseFulfillReactionJobTask or
PromiseRejectReactionJobTask (depending whether you "Fulfill" or
"Reject"). That way the JSPromise class is now only 6 words instead
of 10 words.

Also the PromiseReaction and the reaction tasks can either carry a
JSPromise (for the fast native case) or a PromiseCapability (for the
generic case), which means we don't always pay the overhead of having
to also remember the "deferred resolve" and "deferred reject" handlers
that are only relevant for the generic case anyways.

It also fixes a spec violation where we called "then" before we actually
enqueued the PromiseResolveThenableJob, which is observably wrong.
Calling it later has the advantage that it should be fairly
straight-forward now to completely avoid it for native Promise
instances.

This seems to save around 10-20% on the various Promise benchmarks and
micro-benchmarks. We expect to gain even more as we're now able to
inline various operations into TurboFan optimized code easily.

Bug: v8:7253
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I893d24ca5bb046974b4f5826a8f6dd22f1210b6a
Reviewed-on: https://chromium-review.googlesource.com/892819
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50980}
      8e7737cb
    • Georg Neis's avatar
      Fix bug in async generators. · 9c4c717b
      Georg Neis authored 
      Async generators didn't correctly handle the situation where one calls
.return on a suspended-at-start async generator and passes a
promise-like object whose awaiting causes a new request to the
generator.

Bug: chromium:805729
Change-Id: I4da13ab5bd97f8c2a2c5373242a2d5e2ab0f7f10
Reviewed-on: https://chromium-review.googlesource.com/891231Reviewed-by: 's avatarCaitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50974}
      9c4c717b
  27. 30 Jan, 2018 2 commits
  29. 29 Jan, 2018 3 commits
  31. 24 Jan, 2018 2 commits
  33. 23 Jan, 2018 2 commits
    • Ben L. Titzer's avatar
      [wasm] Reduce usage of frame->wasm_instance() · 66ce6153
      Ben L. Titzer authored 
      As part of the effort to despecialize WASM code, convert many uses of
WasmInstanceObject which were simply indirecting through to either
the compiled module or the shared module data with helpers on
the respective Frame objects.

R=mstarzinger@chromium.org

Bug: 
Change-Id: I05bd1a18b1d81cceef8a80d9f6988e4f5d537e66
Reviewed-on: https://chromium-review.googlesource.com/876125
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50798}
      66ce6153
    • Benedikt Meurer's avatar
      [builtins] Extend the @@species protector to guard Promises. · 79e91f0c
      Benedikt Meurer authored 
      Use this in the PromiseThen operation to skip the (expensive) lookup in
the SpeciesConstructor operation. This yields in a nice 3-5% improvement
on the bluebird and wikipedia benchmarks, and paves the way for inlining
certain Promise operations into TurboFan optimized code later.

On the micro-benchmark mentioned in the bug (from the findings doc), we
reduce the overall execution time by 25%, which makes sense given that
Promise.prototype.then spends a significant portion of it's time just
figuring out the appropriate constructor.

Bug: v8:7253, v8:7349
Change-Id: Ia1577b59d1b7e4b8dbda83e2186583edab76695a
Reviewed-on: https://chromium-review.googlesource.com/880681Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50794}
      79e91f0c
  35. 22 Jan, 2018 3 commits
  37. 19 Jan, 2018 1 commit