Reland Async/await Promise dependency graph

Reland 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)

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

BUG=v8:5167
Committed: https://crrev.com/1b414e283a7db4cca54c6d16e7ccb92c01d27cda
Cr-Commit-Position: refs/heads/master@{#39564}

[Dan Ehrenberg, 2016-09-20 18:00:08]

The CQ bit was checked by littledan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-20 18:00:16]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Dan Ehrenberg, 2016-09-20 18:00:38]

littledan@chromium.org changed reviewers:
+ adamk@chromium.org

[adamk, 2016-09-20 18:03:38]

lgtm

[commit-bot: I haz the power, 2016-09-20 18:04:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-20 18:04:56]

Dry run: Try jobs failed on following builders:
  v8_presubmit on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/24528)

[Dan Ehrenberg, 2016-09-20 18:05:29]

The CQ bit was checked by littledan@chromium.org

[Dan Ehrenberg, 2016-09-20 18:05:30]

The patchset sent to the CQ was uploaded after l-g-t-m from adamk@chromium.org
Link to the patchset: https://codereview.chromium.org/2346363004/#ps20001
(title: "Remove extra newlines")

[commit-bot: I haz the power, 2016-09-20 18:05:36]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-20 19:03:27]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-09-20 19:04:35]

Description was changed from

==========
Reland 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)

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

BUG=v8:5167
==========

to

==========
Reland 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)

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

BUG=v8:5167

Committed: https://crrev.com/1b414e283a7db4cca54c6d16e7ccb92c01d27cda
Cr-Commit-Position: refs/heads/master@{#39564}
==========

[commit-bot: I haz the power, 2016-09-20 19:04:36]

Patchset 2 (id:??) landed as
https://crrev.com/1b414e283a7db4cca54c6d16e7ccb92c01d27cda
Cr-Commit-Position: refs/heads/master@{#39564}

[Michael Achenbach, 2016-09-20 20:26:25]

Could you continue to think about how to make these tests faster? By splitting
them up we might not run into the timeouts, but we still burn quite some
computing time. These tests are still in the top 10 of slowest tests on some
bots, e.g.:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/...

Please check what makes these tests so slow and if really all cases/combinations
that are tested are relevant.

[Dan Ehrenberg, 2016-09-20 20:35:27]

On 2016/09/20 at 20:26:25, machenbach wrote:
> Could you continue to think about how to make these tests faster? By splitting
them up we might not run into the timeouts, but we still burn quite some
computing time. These tests are still in the top 10 of slowest tests on some
bots, e.g.:
>
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/...
> 
> Please check what makes these tests so slow and if really all
cases/combinations that are tested are relevant.

I think we benefit by testing all combinations; in developing the patch, I found
issues in unexpected combinations. On the other hand, I'd be OK with running
these tests only in Release mode, skipping Debug mode, if they are taking
significant testing resources.