BUG=v8:5343

Review-Url: https://codereview.chromium.org/2425553003
Cr-Commit-Position: refs/heads/master@{#40405}

BUG=v8:5343

Review-Url: https://codereview.chromium.org/2415023002
Cr-Commit-Position: refs/heads/master@{#40369}

Review-Url: https://codereview.chromium.org/2419713002
Cr-Commit-Position: refs/heads/master@{#40241}

This patch results in a 11% improvement over 5 runs in the
bluebird benchmark.

BUG=v8:5343,v8:5046
TBR=bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/2406343002
Cr-Commit-Position: refs/heads/master@{#40239}

The behavior was changed in https://codereview.chromium.org/2357423002

Review-Url: https://codereview.chromium.org/2403163002
Cr-Commit-Position: refs/heads/master@{#40142}

This patch sets `this` to be undefined when calling resolve and reject
functions attached to the deferred.

BUG=v8:5476

Review-Url: https://codereview.chromium.org/2399053003
Cr-Commit-Position: refs/heads/master@{#40056}

When we create native promises as part of PromiseThen, we don't have
to create resolving closures. The closure will only ever be called
once from PromiseHandle, therefore we don't need the alreadyResolved
check.

This results in a 21.76% improvement in the bluebird benchmark
over 5 runs.

BUG=v8:5046

Review-Url: https://codereview.chromium.org/2396763002
Cr-Commit-Position: refs/heads/master@{#40018}

Review-Url: https://codereview.chromium.org/2376613003
Cr-Commit-Position: refs/heads/master@{#40011}

Previously passing in the PromiseNopResolver function to the Promise
constructor would result in creating the resolving functions to be in
passed in to the executor, but the PromiseNopResolver does not use
these resolving functions resulting in wastefully creating these closures.

Instead we pass in the promiseRawSymbol to the promise constructor
so that these unnecessary resolving functions are not created.

BUG=v8:5046

Review-Url: https://codereview.chromium.org/2353303003
Cr-Commit-Position: refs/heads/master@{#39791}

This patch tracks the stack of async functions differently from other
Promise async stack tracking. With this patch, the stack trace of a
callstack of async functions should look similarly to the call stack
if all of the functions were synchronous. An example can be found in
the updated test expectations: https://codereview.chromium.org/2362923002 .

The new stack traces are implemented using existing mechanisms in the
inspector. The inspector has two ways to save async stack traces: recurring
and non-recurring stacks. An example of a non-recurring stack is setTimeout,
and a recurring one is saved for setInterval. Recurring stacks are deleted
only when a special "cancel" function is called, rather than being deleted
after being used the first time. Previous Promise async stack tracking always
used non-recurring stacks.

For async functions, this patch saves a recurring stack. The top frame of
the stack is duplicated, as the resuming function contains a similar frame;
the devtools frontend is responsible for removing or marking this frame,
which it can do based on seeing the [async function] line which follows it.
The second frame will instead be provided by the resuming execution
context. The recurring stack is saved when the async function is entered, and
it is deleted from a finally block. The id of the stack is saved in the outer
Promise being constructed by the async function. When an intermediate
throwaway Promise will be triggered as a reaction, it will be identified as
such based on its debugging metadata, and the corresponding async function's
recurring stack will be used.

BUG=v8:4483

Review-Url: https://codereview.chromium.org/2357423002
Cr-Commit-Position: refs/heads/master@{#39695}

- Add a new container object to store the data required for
PromiseResolveThenableJob.

- Create a new runtime function to enqueue the microtask event with
the required data.

This patches causes a 4% regression in the bluebird benchmark.

BUG=v8:5343

Review-Url: https://codereview.chromium.org/2314903004
Cr-Commit-Position: refs/heads/master@{#39571}

To improve performance, this patch makes Promise.all and Promise.race not
perform correct catch prediction when the debugger is not open. The case
may come up if Promise.race or Promise.all is called, then DevTools is
open, then a component Promise is rejected. In this case, the user would
falsely get an exception event even if the "pause on caught exceptions"
box is unchecked. There are tests which triggered this case; however, it
seems both unlikely and and acceptable to have an event in this case.
Many analogous events are already produced when DevTools is enabled
during the operation of a program.

BUG=v8:3093

Review-Url: https://codereview.chromium.org/2350363002
Cr-Commit-Position: refs/heads/master@{#39565}

This patch knits together Promises returned by async/await such that when
one async function awaits the result of another one, catch prediction works
across the boundaries, whether the exception comes synchronously or
asynchronously. Edges are added in three places:
- When a locally uncaught await happens, if the value passed into await
  is a Promise, from the awaited value to the Promise under construction
  in the broader async function
- From a "throwaway" Promise, which may be found on the Promise debug
  stack, to the Promise under construction in the async function that
  surrounds it
- When a Promise is resolved with another Promise (e.g., when returning a
  Promise from an async function)

In this reland, the caught tests are broken up into four parts to avoid
timeouts.

BUG=v8:5167

Review-Url: https://codereview.chromium.org/2346363004
Cr-Commit-Position: refs/heads/master@{#39564}

Revert of Async/await Promise dependency graph (patchset #30 id:550001 of https://codereview.chromium.org/2317383002/ )

Reason for revert:
Need to break up test into smaller tests to avoid timeouts

Original issue's description:
> Async/await Promise dependency graph
>
> This patch knits together Promises returned by async/await such that when
> one async function awaits the result of another one, catch prediction works
> across the boundaries, whether the exception comes synchronously or
> asynchronously. Edges are added in three places:
> - When a locally uncaught await happens, if the value passed into await
>   is a Promise, from the awaited value to the Promise under construction
>   in the broader async function
> - From a "throwaway" Promise, which may be found on the Promise debug
>   stack, to the Promise under construction in the async function that
>   surrounds it
> - When a Promise is resolved with another Promise (e.g., when returning a
>   Promise from an async function)
>
> BUG=v8:5167
>
> Committed: https://crrev.com/7265fdde7c76b9f875b40b0b139515936d491d64
> Cr-Commit-Position: refs/heads/master@{#39522}

TBR=adamk@chromium.org,jgruber@chromium.org,kozyatinskiy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5167

Review-Url: https://codereview.chromium.org/2351953002
Cr-Commit-Position: refs/heads/master@{#39523}

This patch knits together Promises returned by async/await such that when
one async function awaits the result of another one, catch prediction works
across the boundaries, whether the exception comes synchronously or
asynchronously. Edges are added in three places:
- When a locally uncaught await happens, if the value passed into await
  is a Promise, from the awaited value to the Promise under construction
  in the broader async function
- From a "throwaway" Promise, which may be found on the Promise debug
  stack, to the Promise under construction in the async function that
  surrounds it
- When a Promise is resolved with another Promise (e.g., when returning a
  Promise from an async function)

BUG=v8:5167

Review-Url: https://codereview.chromium.org/2317383002
Cr-Commit-Position: refs/heads/master@{#39522}

Handle some examples of the "asynchronous case" by marking await expressions
as either caught or uncaught; in the caught case, this marks the Promise passed
in as having a catch predicted. The marking is done in AST numbering, which
chooses between two different runtime function calls based on catch prediction.

BUG=v8:5167

Review-Url: https://codereview.chromium.org/2276243002
Cr-Commit-Position: refs/heads/master@{#39394}

As part of the work to implement catch prediction for async functions,
the resulting Promise that is the output of the function needs to be
available earlier for a couple reasons:
- To be able to do %DebugPushPromise/%DebugPopPromise over the body
  of the async function
- To be able to pass the resulting promise into AsyncFunctionAwait
  in order to set up the dependency chains

This patch creates the Promise earlier and pushes it onto the debug
stack; a later patch will set up the dependency chain. Although the
debug stack is set up, it's not anticipated that this will change
the catch prediction helpfully yet, as everything will still likely
be predicted as 'caught' for now, as before.

R=caitp@igalia.com,yangguo@chromium.org
CC=neis@chromium.org,gsathya@chromium.org
BUG=v8:5167

Review-Url: https://codereview.chromium.org/2233923003
Cr-Commit-Position: refs/heads/master@{#38957}

This patch fixes up one last case of redundant ExceptionEvents being
triggered in the debugger for Promises--it makes the default reject
handler for Promises (e.g., if the second argument for
Promise.prototype.then is missing) appear to the debugger as a
rethrow.

R=adamk@chromium.org,jgruber@chromium.org
BUG=v8:5167

Review-Url: https://codereview.chromium.org/2278643002
Cr-Commit-Position: refs/heads/master@{#38876}

To make async/await catch prediction work well, this patch regularizes
the exception events sent to DevTools from various places in the Promise
lifecycle. The core is that there should be an exception event when the
rejection first starts, rather than when it is propagated.

- Several cases within Promise code which propagate errors are
  modified to not trigger a new ExceptionEvent in that case, such
  as .then on a rejected Promise and returning a rejected Promise
  from .then, as well as Promise.race and Promise.all.
- Make Promise.reject() create an ExceptionEvent, subject to catch
  prediction based on the Promise stack. This is important
  so that, e.g., if "await Promise.reject()" will trigger a new
  throw (rather than a silent rethrow of something that never
  triggered an event in the first place).

BUG=v8:5167

Review-Url: https://codereview.chromium.org/2244003003
Cr-Commit-Position: refs/heads/master@{#38847}

This flag was shipped on in 52, so it's due for removal. The patch includes
removing the deprecated and unused-in-Blink API Promise::Chain, and many
test updates.

R=adamk@chromium.org
BUG=v8:4633

Review-Url: https://codereview.chromium.org/2267033002
Cr-Commit-Position: refs/heads/master@{#38804}

These were the final remnants of error code written in JavaScript.

BUG=

Review-Url: https://codereview.chromium.org/2222893002
Cr-Commit-Position: refs/heads/master@{#38475}

- Don't read .constructor when returning a Promise from an async function.
  Instead, call out to the internals of Promise.resolve directly.
  This is done by adding back in an "optimization" from an earlier form of
  the async/await code written by Caitlin Potter.
- Async functions always return a new Promise with a distinct identity,
  even if they simply return another Promise.

R=caitp@igalia.com
BUG=v8:4483

Review-Url: https://codereview.chromium.org/2219623002
Cr-Commit-Position: refs/heads/master@{#38404}

The `PerformPromiseThen` spec-internal operation is used by the async functions
proposal, in order to ensure that AwaitExpressions are not observable via
usual mechanisms/hooks, such as Symbol.species.

BUG=v8:5253
R=littledan@chromium.org, adamk@chromium.org, gsathya@chromium.org, yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2209433003
Cr-Commit-Position: refs/heads/master@{#38353}

Promise.resolve

Instead of creating resolve and reject closures, directly
call ResolvePromise after creating the promise.

Using the following as a microbenchmark --
```
var b = 0;
var start = performance.now();
for (var i = 0; i < 1000000; i++) {
  Promise.resolve(1).then((val) => {
    b += val;
    if (b == 1000000) print(performance.now() - start)
  });
}
```

I see a 16.01% improvement over 5 runs with this patch.

BUG=v8:5046

Review-Url: https://codereview.chromium.org/2143553002
Cr-Commit-Position: refs/heads/master@{#38318}

BUG=v8:5046

Review-Url: https://codereview.chromium.org/2209773003
Cr-Commit-Position: refs/heads/master@{#38316}

This is in preparation to implementing exception prediction for async
functions.  Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.

To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
prediction.

The previous implementation of using the function to tell the relevant
try-catch apart from inner try-catch blocks will not work for async functions
since these can have inner try-catch blocks inside the same function.

BUG=v8:5167

Review-Url: https://codereview.chromium.org/2161263003
Cr-Commit-Position: refs/heads/master@{#37966}

Flags removed (all begin with "harmony-"):
  function-name
  instanceof
  iterator-close
  unicode-regexps
  regexp-exec
  regexp-subclass
  species

BUG=v8:3566, v8:3648, v8:3699, v8:4093, v8:4447, v8:4602

Review-Url: https://codereview.chromium.org/2096933002
Cr-Commit-Position: refs/heads/master@{#37235}

This patch adds a test for async/await analogous to a previous Promise test.
It also fixes a typo in promise.js and makes a previous Promise test more
correct by ensuring that all assertions run before completion, fixing the
test expectations for the real result (which seems correct).

BUG=v8:4483
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/2037653002
Cr-Commit-Position: refs/heads/master@{#36903}

Revert of Promises: Make PromiseSet operation monomorphic (patchset #1 id:1 of https://codereview.chromium.org/2025073002/ )

Reason for revert:
As a side effect of calling PromiseSet from
FulfillPromise, clears the deferred symbol and the
resolve/reject callback symbols. Although this
isn't strictly necessary, not doing this seems to
result in a leak as seen in --

https://bugs.chromium.org/p/chromium/issues/detail?id=617137#c10

Original issue's description:
> Promises: Make PromiseSet operation monomorphic
>
> The PromiseSet operation is called with two types of promises
> 1) A newly created promise object with no properties
> 2) Promise object with callbacks and other properties
>
> PromiseSet is called with the first type of promise (with no
> properties) from multiple call sites. PromiseSet is called with the
> second type of promise object only from FulfillPromise. Furthermore,
> this call only sets the value and status of the promise, the rest of
> the values are reset to UNDEFINED (which isn't necessary).
>
> This patch inlines the calls to set the value and status of the
> promise in FulfillPromise, instead of calling out to PromiseSet.
>
> This patch also reduces the number of symbol lookups, as we only set
> the value and status of the promise, and don't change the callback or
> deferred symbols.
>
> This patch results in a performance improvement of 2.8% over 5 runs in
> the bluebird benchmark.
>
> BUG=v8:5046
>
> Committed: https://crrev.com/df4f8a2b9ee9e474e674301718d19b63650a0ba5
> Cr-Commit-Position: refs/heads/master@{#36688}

TBR=littledan@chromium.org,adamk@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:5046

Review-Url: https://codereview.chromium.org/2047553002
Cr-Commit-Position: refs/heads/master@{#36766}

When |ResolvePromise| is resolved with a promise that is
already fulfilled or resolved, we can short circuit the
promise resolution procedure by directly looking up the
result from the promise. We save creating two closures, enqueuing in
the promise queue, and running through PromiseThen.

This patch uses IsPromise to check if the |resolution| object is a native
promise and also checks if |resolution.then| hasn't been monkey
patched.

This patch adds some redundant code from PromiseThen like setting
the promiseHasHandlerSymbol and calling PromiseRevokeReject call,
which would've been taken care of by PromiseThen in the old code path.

This patch results in a 13.8% improvement(over 5 runs) in the bluebird
benchmarks.

BUG=v8:5046

Review-Url: https://codereview.chromium.org/2028253004
Cr-Commit-Position: refs/heads/master@{#36765}

The PromiseSet operation is called with two types of promises
1) A newly created promise object with no properties
2) Promise object with callbacks and other properties

PromiseSet is called with the first type of promise (with no
properties) from multiple call sites. PromiseSet is called with the
second type of promise object only from FulfillPromise. Furthermore,
this call only sets the value and status of the promise, the rest of
the values are reset to UNDEFINED (which isn't necessary).

This patch inlines the calls to set the value and status of the
promise in FulfillPromise, instead of calling out to PromiseSet.

This patch also reduces the number of symbol lookups, as we only set
the value and status of the promise, and don't change the callback or
deferred symbols.

This patch results in a performance improvement of 2.8% over 5 runs in
the bluebird benchmark.

BUG=v8:5046

Review-Url: https://codereview.chromium.org/2025073002
Cr-Commit-Position: refs/heads/master@{#36688}

There are 2 possible states for the deferred symbol --
1) UNDEFINED -- This is the zero state, no deferred object is attached
   to this symbol. When we want to add a new deferred we directly
   attach it to this symbol.
2) symbol with attached deferred object -- New deferred objects are
   not attached to this symbol, but instead they are directly attached
   to the resolve, reject callback arrays. At this point, the deferred
   symbol's state is stale, and the deferreds should be read from the
   reject, resolve callbacks.

BUG=v8:5046

Review-Url: https://codereview.chromium.org/2018913004
Cr-Commit-Position: refs/heads/master@{#36623}

This got left behind from the changes in
https://codereview.chromium.org/2007803002/

PromiseSet only takes 3 arguments.

BUG=v8:5046

Review-Url: https://codereview.chromium.org/2016183002
Cr-Commit-Position: refs/heads/master@{#36556}

For the common use case of having a single resolve or reject callback,
the callbacks are stored directly. Only when an additional callback is
registered, we create an array to store these callbacks.

There are 3 possible states for the resolve, reject symbols when we add
a new callback --
1) UNDEFINED -- This is the zero state where there is no callback
registered. When we see this state, we directly attach the callbacks to
the symbol.
2) !IS_ARRAY -- There is a single callback directly attached to the
symbols. We need to create a new array to store additional callbacks.
3) IS_ARRAY -- There are multiple callbacks already registered,
therefore we can just push the new callback to the existing array.

Also, this change creates a new symbol for storing the deferred objects.
Previously the deferred objects were stored in the callback arrays, but
since we no longer create arrays for the initial case, we need this new
symbol. The cctest has been updated to account for this new symbol.

This patch results in a 19% improvement(over 5 runs) in the bluebird benchmark.

BUG=v8:5046

Review-Url: https://codereview.chromium.org/2007803002
Cr-Commit-Position: refs/heads/master@{#36536}

Review-Url: https://codereview.chromium.org/2001283006
Cr-Commit-Position: refs/heads/master@{#36535}

Previously, certain calls to DebugPushPromise and DebugPopPromise
happened always, without any check to see if we were in a debugging
environment. This patch adds a conditional check before making these
debug calls to make sure they aren't called when not needed.

Before the patch, running --prof over the bluebird benchmarks,
brings up these unprotected debug calls --
ticks    cpp   total   name
16    6.7%    2.0%  v8::internal::Runtime_DebugPushPromise(int, v8::internal::Object**, v8::internal::Isolate*)
7    2.9%    0.9%  v8::internal::Runtime_DebugPopPromise(int, v8::internal::Object**, v8::internal::Isolate*)

This patch removes the above calls and provides a 4% improvement (with
a 2% variance over 10 runs) in the bluebird benchmark.

Review-Url: https://codereview.chromium.org/1985293002
Cr-Commit-Position: refs/heads/master@{#36451}

BUG=v8:4483
LOG=N
R=littledan@chromium.org, adamk@chromium.org

Review-Url: https://codereview.chromium.org/1895603002
Cr-Commit-Position: refs/heads/master@{#36263}

The Promise code previously used many names which were gratuitiously
different from the specification. This patch swaps in names from the
ES2015 spec, and inserts crossreferences to the spec. The patch
leaves mirrors over Promises unchanged for now, as these changes
could have compatibility risk.

R=cbruni@chromium.org

Review-Url: https://codereview.chromium.org/1919143004
Cr-Commit-Position: refs/heads/master@{#35962}

We decided to remove related devtools experiment.

BUG=chromium:526811
LOG=Y
R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/1833563002

Cr-Commit-Position: refs/heads/master@{#35275}

This should help speeding up Promise and RegExp instantiations substantially.

BUG=

Review URL: https://codereview.chromium.org/1850643002

Cr-Commit-Position: refs/heads/master@{#35200}