1315620 - Optimize out resolved promise allocation in await.

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect, P3)

Description

[Tooru Fujisawa [:arai]]

(separated from bug 1314055, based on bug 1315559)

https://tc39.github.io/ecmascript-asyncawait/#abstract-ops-async-function-await

AsyncFunctionAwait creates resolved promise from passed value, and call then on it.
if passed promise is not modified and not subclassed, we could optimize out allocation of the resolved promise, and use passed promise directly.

Comment 1

[Tooru Fujisawa [:arai]]

main concern is execution timing:
  1. it may cause the execution out of order (2 jobs vs 1 job)
  2. mis-optimization because of the passed promise or prototype can be modified between when we check the if it's optimizable and when we actually perform "then"

Comment 2

[Till Schneidereit [:till]]

(In reply to Tooru Fujisawa [:arai] from comment #1)
> main concern is execution timing:
>   1. it may cause the execution out of order (2 jobs vs 1 job)
>   2. mis-optimization because of the passed promise or prototype can be
> modified between when we check the if it's optimizable and when we actually
> perform "then"

Both of these concerns apply to all potential optimizations of thenables handling, yes. My basic plan is to introduce a type of promise job that can delay itself one turn - essentially, the first time it is called it immediately re-enqueues itself. Extending that to handle thenables seems fairly straight-forward. All of this would be easier if we first change JSRuntime::enqueuePromiseJob to take a JSObject instead of a JSFunction, with an added JSAPI function ExecutePromiseJob that knows how to handle a job. This object would be a PromiseReactionRecord containing the required information.

bz tells me that changing Gecko to enable JSObjects as promise jobs instead of JSFunctions wouldn't be trivial though, so this won't happen right-away.

Comment 3

[Tooru Fujisawa [:arai]]

filed bug 1315756 for optimizing throwawayCapability out, that is in step 7
https://tc39.github.io/ecmascript-asyncawait/#abstract-ops-async-function-await

to be clear, this bug corresponds to step 2.

Comment 4

[Julien Cristau [:jcristau]]

Mass wontfix for bugs affecting firefox 52.

Comment 5

[Matthew Gaudet (he/him) [:mgaudet]]

As I read this bug, it seems to me this behaviour is now specified as part of 27.2.4.7.1 PromiseResolve ( C, x ); have I misunderstood or can we close this bug?

Comment 6

[Tooru Fujisawa [:arai]]

Yes, the promise allocation around await had been rewritten in the spec, and this issue no longer exists.