Implement Microtask Delivery Queue

Implement Microtask Delivery Queue

R=rossberg@chromium.org, rossberg
BUG=

Committed: https://code.google.com/p/v8/source/detail?r=19084

[rafaelw, 2014-01-24 00:18:34]

https://codereview.chromium.org/131413008/diff/30001/src/v8natives.js
File src/v8natives.js (right):

https://codereview.chromium.org/131413008/diff/30001/src/v8natives.js#newcode...
src/v8natives.js:1912: RunMicrotasks.queue = new InternalArray;
I'm tempted to avoid allocating a new InternalArray for every pass here, and
instead just set queue.length = 0 at the end of the function.

I guess you'd need to protect against overflow within a single pass. What do you
think?

https://codereview.chromium.org/131413008/diff/30001/test/mjsunit/harmony/mic...
File test/mjsunit/harmony/microtask-delivery.js (right):

https://codereview.chromium.org/131413008/diff/30001/test/mjsunit/harmony/mic...
test/mjsunit/harmony/microtask-delivery.js:98: assertOrdering(['p1', 'p2',
'p1:1', 'p2:1']);
This patch isn't changing this ordering (I checked). This test would have passed
before this patch.

However, in talking with Alex Russel, I got the impression that Promises are
supposed to "fast-forward" to the next "then" which is a promise.

In other words, I was expecting this to be 'p1', 'p1:1', 'p2', 'p2:2'.

[rafaelw, 2014-01-24 17:10:28]

a little cleanup

[rossberg, 2014-02-04 13:50:08]

lgtm

https://codereview.chromium.org/131413008/diff/80001/src/promise.js
File src/promise.js (right):

https://codereview.chromium.org/131413008/diff/80001/src/promise.js#newcode185
src/promise.js:185: function HandlePromise(value, handler, deferred) {
Nit: call this PromiseHandle for consistency

https://codereview.chromium.org/131413008/diff/80001/test/cctest/test-microta...
File test/cctest/test-microtask-delivery.cc (right):

https://codereview.chromium.org/131413008/diff/80001/test/cctest/test-microta...
test/cctest/test-microtask-delivery.cc:65: "function handler(resolve) {
resolver.resolve = resolve; }"
Nit: any reason why you don't just use "resolver = resolve"?

https://codereview.chromium.org/131413008/diff/80001/test/mjsunit/harmony/mic...
File test/mjsunit/harmony/microtask-delivery.js (right):

https://codereview.chromium.org/131413008/diff/80001/test/mjsunit/harmony/mic...
test/mjsunit/harmony/microtask-delivery.js:122: assertOrdering(['p1', 'o1',
'o2', 'p2', 'o1', 'o3', 'p3']);
Whew, I had to stare at this for 10 minutes to figure out why this is the
expected outcome. I fear we are in for a major WTF from programmers with this
semantics...

[rafaelw, 2014-02-04 19:57:15]

all done. note that in order to fix a few tests, I needed to add a HandleScope
in runtime.cc and to exempt %RunMicrotasks in fuzz-natives-part3.js. I'm

https://codereview.chromium.org/131413008/diff/80001/src/promise.js
File src/promise.js (right):

https://codereview.chromium.org/131413008/diff/80001/src/promise.js#newcode185
src/promise.js:185: function HandlePromise(value, handler, deferred) {
On 2014/02/04 13:50:08, rossberg wrote:
> Nit: call this PromiseHandle for consistency

Done.

https://codereview.chromium.org/131413008/diff/80001/test/cctest/test-microta...
File test/cctest/test-microtask-delivery.cc (right):

https://codereview.chromium.org/131413008/diff/80001/test/cctest/test-microta...
test/cctest/test-microtask-delivery.cc:65: "function handler(resolve) {
resolver.resolve = resolve; }"
On 2014/02/04 13:50:08, rossberg wrote:
> Nit: any reason why you don't just use "resolver = resolve"?

Done.

https://codereview.chromium.org/131413008/diff/80001/test/mjsunit/harmony/mic...
File test/mjsunit/harmony/microtask-delivery.js (right):

https://codereview.chromium.org/131413008/diff/80001/test/mjsunit/harmony/mic...
test/mjsunit/harmony/microtask-delivery.js:122: assertOrdering(['p1', 'o1',
'o2', 'p2', 'o1', 'o3', 'p3']);
Yeah. I know. My hope is that most developers won't ever have to care about
delivery order. For sure, those that do will be sad. If you have ideas about how
to improve this, don't be shy.

On 2014/02/04 13:50:08, rossberg wrote:
> Whew, I had to stare at this for 10 minutes to figure out why this is the
> expected outcome. I fear we are in for a major WTF from programmers with this
> semantics...

[rafaelw, 2014-02-04 19:58:56]

Committed patchset #4 manually as r19084 (presubmit successful).