Fix async/await memory leak

src/js/harmony-async-await.js

Index: src/js/harmony-async-await.js
diff --git a/src/js/harmony-async-await.js b/src/js/harmony-async-await.js
index 0d470bbe8c84300dfcd9213ba1becb016294bd40..0f66c57f4d97e29912cdbef9d10b5cca5f2e22eb 100644
--- a/src/js/harmony-async-await.js
+++ b/src/js/harmony-async-await.js
@@ -67,8 +67,14 @@ function AsyncFunctionAwait(generator, awaited, outerPromise) {
   // );
   var promise = PromiseCastResolved(awaited);
 
-  var onFulfilled =
-      (sentValue) => %_Call(AsyncFunctionNext, generator, sentValue);
+  var onFulfilled = (sentValue) => {
+    %_Call(AsyncFunctionNext, generator, sentValue);
+    // The resulting Promise is a throwaway, so it doesn't matter what it

[caitp, 2016/09/15 20:18:40]

don't we have this same problem in the rejection case?

[Dan Ehrenberg, 2016/09/15 20:24:21]

I don't think so; we don't have the whole chaining thing going on in the
rejection case.

[caitp, 2016/09/15 20:32:23]

Either way, I think it would still be good to add a similar test for

```
async function longLoop2() {
   for (let i = 0; i < 100000; i++) {
     try {
       await thrower();
     } catch (e) {
     }
   }
   out = 1;
}
```

although it might take too long.

[Dan Ehrenberg, 2016/09/15 20:37:58]

Oh, you're actually right. It'd similarly take keeping the whole chain alive to
figure out the rejection that things should resolve to. I reproduced this in a
test, and made a fix in the code, explaining in a comment.

+    // resolves to. What is important is that we don't end up keeping the
+    // whole chain of intermediate Promises alive by returning the value
+    // of AsyncFunctionNext, as that would create a memory leak.
+    return UNDEFINED;
+  };
   var onRejected =
       (sentError) => %_Call(AsyncFunctionThrow, generator, sentError);