Skip to content

V
V8
Switch branch/tag
  1. 15 Oct, 2018 4 commits
  3. 12 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] Introduce the notion of a "current microtask". · 9f28c129
      Benedikt Meurer authored 
      Change the way we start collecting async stack traces by storing the
current microtask as a root instead of trying to make sense of the
last frame we see. This makes it possible to use the zero cost async
stack traces in Node.js as well (where the last JavaScript frame we
see is not the actual async function, but some frame related to the
main event loop usually).

In addition to the benefit that it now works with Node.js, we can also
extend the new machinery to look through (almost arbitrary) promise
chains. For example this code snippet

```js
(async function() {
  await Promise.resolve().then(() =>
    console.log(new Error().stack));
})();
```

can be made to also show the async function frame, even though at the
point where the stack trace is collected we don't have any async
function on the stack. But instead there's a PromiseReactionJobTask
as "current microtask", and we can dig into the chained promise to
see where the async execution is going to continue and eventually
find the await promise in the chain.

This also removes the removes the need to allocate `.generator_object`
specially during scope resolution.

Bug: v8:7522
Ref: nodejs/node#11865
Tbr: ulan@chromium.org
Design-Document: bit.ly/v8-zero-cost-async-stack-traces
Change-Id: Ib96cb17c2f75cce083a24e5ba2bbb7914e20d203
Reviewed-on: https://chromium-review.googlesource.com/c/1277505
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56590}
      9f28c129
  5. 11 Oct, 2018 7 commits
  7. 10 Oct, 2018 7 commits
    • Junliang Yan's avatar
      make kWasmCompileLazyFuncIndexRegister naming consistent · d0b6bdfd
      Junliang Yan authored 
      R=titzer@chromium.org

Change-Id: Ia39d4ec981e6a539cc7466c7b20ff5bd85a49090
Reviewed-on: https://chromium-review.googlesource.com/c/1274266Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#56543}
      d0b6bdfd
    • Junliang Yan's avatar
      s390x: [wasm] Use a name for the lazy compile func index · bc2d6ccf
      Junliang Yan authored 
      Port 4cbec82c

Original Commit Message:

    Pure refactoring CL. Introduce a symbolic name for the register
    used to hold the function index when calling the lazy compile stub.
    This makes it easier to see this contract when looking at the
    macro assembler.

R=titzer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I320373dfe4734b27b85217a829bf574bc7b90a2d
Reviewed-on: https://chromium-review.googlesource.com/c/1273825Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#56536}
      bc2d6ccf
    • Mike Stanton's avatar
      [Builtins] Array.prototype.splice performance improvements · 696b2ced
      Mike Stanton authored 
      a) The current size of the backing store for the array under splice
    wasn't considered. Additionally, allocate the array with the
    normal growing strategy.

b) Use primitives memcpy and memmove when
   appropriate. These calls are wrapped in new CSA functions
   MoveElements and CopyElements, which use the C functions when a
   write barrier isn't needed (otherwise they just copy elements
   in a loop).

Bug: chromium:880780
Change-Id: I39a917c71036f52250c68f2cced77a1c24f97b67
Reviewed-on: https://chromium-review.googlesource.com/c/1243104
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56534}
      696b2ced
    • Ben L. Titzer's avatar
      [wasm] Use a name for the lazy compile func index · 4cbec82c
      Ben L. Titzer authored 
      Pure refactoring CL. Introduce a symbolic name for the register
used to hold the function index when calling the lazy compile stub.
This makes it easier to see this contract when looking at the
macro assembler.

R=ahaas@chromium.org
CC=clemensh@chromium.org

Change-Id: I714f978883ced001a1435338dcefd96744bfb2ae
Reviewed-on: https://chromium-review.googlesource.com/c/1273099
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56516}
      4cbec82c
    • Benedikt Meurer's avatar
      [esnext] Implement "Editorial: refactor PerformPromiseThen to allow no capability". · e24b95dc
      Benedikt Meurer authored 
      This implements the editorial change in https://github.com/tc39/ecma262/pull/1146
which removes the need to allocate the throwaway promise in await (the throwaway
promise was not exposed to user JavaScript anyways, but this spec change allows
us to rely on this behavior). Now we still need the throwaway promise for proper
before and after events with both DevTools (which might change) and PromiseHooks.
So if either DevTools or PromiseHooks is on, we call into %AwaitPromisesInit,
which then allocates the throwaway promise and does all the other debugger/hooks
related setup.

This gives around 7% improvement on the doxbee-async-es2017-native and around 1-2%
on the parallel-async-es2017-native benchmarks.

Bug: v8:7253, v8:8285
Ref: tc39/ecma262#1146
Tbr: ulan@chromium.org
Change-Id: I972ba0538ec8c00808e95b183603025c7e55a6d3
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1270798
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56506}
      e24b95dc
    • Benedikt Meurer's avatar
      [async] Improve async function handling. · 0038e5f0
      Benedikt Meurer authored 
      This change introduces new intrinsics used to desugar async functions
in the Parser and the BytecodeGenerator, namely we introduce a new
%_AsyncFunctionEnter intrinsic that constructs the generator object
for the async function (and in the future will also create the outer
promise for the async function). This generator object is internal
and never escapes to user code, plus since async functions don't have
a "prototype" property, we can just a single map here instead of tracking
the prototype/initial_map on every async function. This saves one word
per async function plus one initial_map per async function that was
invoked at least once.

We also introduce two new intrinsics %_AsyncFunctionReject, which
rejects the outer promise with the caught exception, and another
%_AsyncFunctionResolve, which resolves the outer promise with the
right hand side of the `return` statement. These functions also perform
the DevTools part of the job (aka popping from the promise stack and
sending the debug event). This allows us to get rid of the implicit
try-finally from async functions completely; because the finally
block only called to the %AsyncFunctionPromiseRelease builtin, which
was used to inform DevTools.

In essence we now turn an async function like

```js
async function f(x) { return await bar(x); }
```

into something like this (in Parser and BytecodeGenerator respectively):

```
function f(x) {
  .generator_object = %_AsyncFunctionEnter(.closure, this);
  .promise = %AsyncFunctionCreatePromise();
  try {
    .tmp = await bar(x);
    return %_AsyncFunctionResolve(.promise, .tmp);
  } catch (e) {
    return %_AsyncFunctionReject(.promise, e);
  }
}
```

Overall the bytecode for async functions gets significantly shorter
already (and will get even shorter once we put the outer promise into
the async function generator object). For example the bytecode for a
simple async function

```js
async function f(x) { return await x; }
```

goes from 175 bytes to 110 bytes (a ~38% reduction in size), which
is in particular due to the simplification around the try-finally
removal.

Overall this seems to improve the doxbee-async-es2017-native test by
around 2-3%. On the test case mentioned in v8:8276 we go from
1124ms to 441ms, which corresponds to a 60% reduction in total
execution time!

Tbr: marja@chromium.org
Bug: v8:7253, v8:7522, v8:8276
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4
Reviewed-on: https://chromium-review.googlesource.com/c/1269041
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56502}
      0038e5f0
    • Igor Sheludko's avatar
      [cleanup] Split the mutable roots list into immovable and movable · 33ebe358
      Igor Sheludko authored 
      ... and remove Heap::RootCanBeWrittenAfterInitialization() and
Heap::RootCanBeTreatedAsConstant() in favour of RootsTable::IsImmortalImmovable().

Bug: v8:8238
Change-Id: I804d06136de9584b8c4940fd8ab9d18fb3ef7980
Reviewed-on: https://chromium-review.googlesource.com/c/1270837
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56500}
      33ebe358
  9. 09 Oct, 2018 2 commits
  11. 08 Oct, 2018 6 commits
  13. 06 Oct, 2018 2 commits
  15. 05 Oct, 2018 3 commits
  17. 04 Oct, 2018 6 commits
  19. 03 Oct, 2018 2 commits