Normative: Reduce the number of ticks in async/await

[MayaLekova]

JavaScript programmers may expect that the following
two programs are largely similar in terms of how they perform with
respect to the ECMAScript job queue (if inside of an async function):

promise.then(f); f(await promise);

However, if promise is a built-in promise, then these two code fragments
will differ in the number of iterations through the job queue are taken: because
await always wraps a Promise with another Promise, there are three job
queue items enqueued and dequeued before calling f in the await example,
whereas there is just a single item for the then usage.

In discussions with JavaScript programmers, the number of job queue items
in the current semantics turns out to be surprising. For example, the difference
has become more visible in conjunction with new V8 features for Promise
visibility and debugging, which are sometimes used in Node.js.

This patch changes the semantics of await to reduce the number of
job queue turns that are taken in the common await Promise case by replacing
the unconditional wrapping with a call to PromiseResolve. Analogous changes
are made in async iterators.

The patch preserves key design goals of async/await:

• Job queue processing remains deterministic, including both ordering and the number of jobs enqueued (which is observable by interspersing other jobs)
• Userland Promise libraries with "then" methods ("foreign thenables") are usable within await, and trigger a turn of the job queue
• Non-Promises can be awaited, and this takes a turn of the native job queue (as do all usages of await)

Reducing the number of job queue turns also improves performance
on multiple highly optimized async/await implementations. In a draft
implementation of this proposal in V8 behind a flag [1]:

• The doxbee async/await performance benchmark [2] improved with 48%
• The fibonacci async/await performance benchmark [3] improved with 23%
• The Hapi throughput benchmark [4] improved with 50% (when async hooks are enabled) and with 20% (when async hooks are disabled)

[1] https://chromium-review.googlesource.com/c/v8/v8/+/1106977
[2] https://github.com/bmeurer/promise-performance-tests/blob/master/lib/doxbee-async.js
[3] https://github.com/bmeurer/promise-performance-tests/blob/master/lib/fibonacci-async.js
[4] https://github.com/fastify/benchmarks

[MayaLekova]

Please note a possible issue of this change noted by @zenparsing in the original commit. Any feedback on what's the importance of this issue and suggestions how it can be worked around are more than welcome!

[ljharb]

I like that this change leaves await robust, and uses the existing PromiseResolve mechanism. I think this also relates to #1118.

[domenic]

LGTM, and seems like a great consistency improvement to use PromiseResolve() more. (Compare to Promise.prototype.finally.)

[zenparsing]

Thanks for the detailed write-up and benchmarks!

[zenparsing]

PromiseResolve currently takes a constructor in the first argument position. I suppose that we'll need to provide it with %Promise%.

[benjamn]

What are the chances we could tolerate any Promise subclass here? In other words, pass value.constructor as the first argument to PromiseResolve if value instanceof %Promise% (pardon my hand waving; there may be a better spec notation for this), thereby giving value a chance to be returned as-is by PromiseResolve.

I realize the async function can only return instances of the original, native Promise constructor, but it seems like a good thing for await to treat Promise subclasses the same way it treats ordinary Promises.

Unless part of the deal with subclassing Promise is that you're guaranteed your .prototype.then method will be called by await?

I don't have strong feelings either way, but it seems like a discussion worth having.

[zenparsing]

A Promise subclass would (presumably) fail the SameValue test on 2.b of PromiseResolve, and we would then fallback to creating a new promise (exactly as we currently do).

[ljharb]

I believe it was an intentional design decision, discussed in committee, not to support subclassed Promises in await.

[ljharb]

(Specifically, using .constructor here would mean that any object coercible value in the language would pass the test in PromiseResolve, which would break the semantics)

[benjamn]

So it's exactly as if await calls Promise.resolve, which passes this as the constructor argument to PromiseResolve. Although this could be a subclass of Promise in arbitrary user code, it would always be %Promise% in an async function.

[benjamn]

(Specifically, using .constructor here would mean that any object coercible value in the language would pass the test in PromiseResolve, which would break the semantics)

That's why we would have to perform an external check that .constructor is a Promise subclass before calling PromiseResolve(_value_.constructor, _value_), or perhaps modify PromiseResolve to enforce the subclass relationship.

How do folks feel about introducing a single-argument PromiseResolve variant that does the right thing (whatever we decide that is), so that this code (i.e. Let _promise_ be ? PromiseResolve(« _value_ »)) works as written?

[zenparsing]

I would probably prefer the explicit constructor argument to PromiseResolve for now. And I believe it should be %Promise% in any case: subclasses should go through the slower but semantically more flexible path of calling their overridden "then" method from a new tick.

[ljharb]

I also think it's useful to keep the explicit %Promise%.

[MayaLekova]

Thanks for the discussion!
Added %Promise% as a parameter in a follow-up commit.

[zenparsing]

I'm curious about what the group thinks about the issue that @MayaLekova referenced upthread: with these new semantics "then" will not be called on a native, non-subclassed promise when awaited (because we are doing PerformPromiseThen directly):

async function f() {
  let promise = Promise.resolve(1);
  promise.then = function(...args) {
    print('then called');
    return Promise.prototype.then.apply(this, args);
  };
  let result = await promise;
  return result;
}

f().then(v => print(v));

Currently, we log "then called", but I think after the change we will not. Is this edge case a problem that we should worry about?

[ljharb]

Since it’s only observable if you monkeypatch the then method, and since Promise.resolve behaves this way already, and since await is often described as conceptually wrapping its operand in Promise.resolve, it seems like the proper choice to me - and anyone relying on this behavior already can’t necessarily rely on it happening.

[benjamn]

@ljharb You're right, monkey-patching Promise.prototype.then is already broken in the sense that .then doesn't get called by await reliably enough to do anything useful, such as automatically propagating some sort of async context data.

An alternative approach is to wrap await expressions within the async function body (or use a transform that does the wrapping automatically). For example, await <expr> could be transformed to captureContext()(await <expr>), where captureContext is something like:

function captureContext() {
  const context = getCurrentContext();
  return function restoreContext(value) {
    setCurrentContext(context);
    return value;
  };
}

I hope we (TC39) can keep entertaining potential solutions for this kind of use case, such as Node's AsyncResource API, but I very much agree that wrapping Promise.prototype.then is not the way to get there, so it's fine that this PR slightly interferes with that strategy.

[MayaLekova]

Rebased the commits on top of master.

Here are the links to the original changes, for the purpose of comment tracking:
Version 1
Version 2

Big thanks to @littledan for wording the commit message!

[zenparsing]

Following up on this.

At the previous TC39 meeting, @erights brought up a use case for monkey-patching Promise.prototype.then. If I remember correctly, a user may want to monkey-patch then such that it always returns a frozen promise object.

Does this change negatively impact that use case? I don't think so. Even with the current semantics, the promise that gets returned from p.then as a result of await p isn't observable to user code.

In general, a "useful" then monkey-patch is going to do one or more of the following:

• Create side-effects
• Modify the return value
• Wrap the input callbacks

I think we are correct to discourage side effects triggered by await, for performance reasons.

A monkey-patch that modifies the return value (e.g. the frozen promise use case) will not be impacted by this change, since the return value is always discarded anyway.

What about a monkey-patch that wraps the input callbacks (e.g. for "async zone" tracking)? Under the current semantics, such a monkey-patch will only see a native "resolve" and "reject" function as a result of await p. Because calling those functions will never result in the execution of user code, it's difficult to see how wrapping them can be useful currently.

It seems to me that this change does not significantly impact "reasonable" monkey-patching use cases.

Thoughts?