Intent to Implement Promises in V8

[Yutaka Hirano]

Promises are currently being specified at [1] and according to [2] they will be introduced in ES6.

I would like to implement them behind a flag.

The implementation will replace the Promises implementation in Blink in the future.

 Other implementations

Promises are also defined in whatwg[3] and some web browsers are implementing it.

 - WebKit https://bugs.webkit.org/show_bug.cgi?id=120954

 - Blink https://code.google.com/p/chromium/issues/detail?id=243345

 - Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=911216

 Technical considerations

Promises need an asynchronous task execution mechanism.

Currently I plan to provide a "postTask" function from Blink to V8.

[1] https://github.com/domenic/promises-unwrapping/blob/master/README.md

[2] https://mail.mozilla.org/pipermail/es-discuss/2013-September/033560.html

[3] http://dom.spec.whatwg.org/#promises

[Jochen Eisinger]

On Fri, Oct 4, 2013 at 12:19 PM, Yutaka Hirano <yhi...@chromium.org> wrote:

Promises are currently being specified at [1] and according to [2] they will be introduced in ES6.

I would like to implement them behind a flag.

The implementation will replace the Promises implementation in Blink in the future.

 Other implementations

Promises are also defined in whatwg[3] and some web browsers are implementing it.

 - WebKit https://bugs.webkit.org/show_bug.cgi?id=120954

 - Blink https://code.google.com/p/chromium/issues/detail?id=243345

 - Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=911216

 Technical considerations

Promises need an asynchronous task execution mechanism.

Currently I plan to provide a "postTask" function from Blink to V8.

We're currently working on adding a threading API, probably similar to blink's WebThread.

best

-jochen

 

[1] https://github.com/domenic/promises-unwrapping/blob/master/README.md

[2] https://mail.mozilla.org/pipermail/es-discuss/2013-September/033560.html

[3] http://dom.spec.whatwg.org/#promises

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Dmitry Lomov]

Implementing behind the flag LGTM.

There is clear consensus among TC39 members, browser vendors and web platform champions that Promises are an important addition to ECMAScript. At a Sept TC39 meeting, promises has been put on a fast track to ES6 - the next release of ECMAScript spec. Also, Modules - another important ES6 feature - are likely to take dependency on promises.

There is a broad consensus on the API as well.

I have a couple of points re your intent-to-implement though:

- please clarify your testing plans, both w.r.t. conformance and performance

- as Jochen mentioned, let's work together to fit promises' needs into a larger work to unify threading between Blink and V8

- generally, it will be nice to have a design document describing promises implementation (maybe there is one already and I missed it?)

Thanks and cheers,

Dmitry

former F# asynchrony guy: http://goo.gl/Z3RhB8

On Fri, Oct 4, 2013 at 12:19 PM, Yutaka Hirano <yhi...@chromium.org> wrote:

[Dirk Pranke]

On Fri, Oct 4, 2013 at 3:29 AM, Jochen Eisinger <joc...@chromium.org> wrote:

We're currently working on adding a threading API, probably similar to blink's WebThread.

We are?

-- Dirk

 

[Jochen Eisinger]

To clarify, we won't expose threads to the language, but clean-up the thread usage of V8 internally, e.g. the optimizing compiler thread.

best

-jochen

[Yusuke SUZUKI]

We're currently working on adding a threading API, probably similar to blink's WebThread.

Sounds very nice. Providing embedder-side's threading operation interfaces to V8 is needed for Promises.

Is there already any discussion about design of a threading API?

[Vyacheslav Egorov]

Recently I was made aware of a user land promises library that Petka Antonov (cced) implemented with the focus on performance.

https://github.com/petkaantonov/bluebird

There seem to be some meaningful benchmarks mentioned there in the section about Benchmarking. 

You might be interested in taking a look at his code.

Vyacheslav Egorov

[Petka Antonov]

The benchmark is emulating a server side workflow. I don't imagine there is anything like that needed on client side.

On client side you could be calculating fibonacci numbers for fun in the promise internals and no-one would notice anything. Although on client-side for some use-cases it's important to use
a fast scheduler like a MutationObserver.

Petka

[Dmitry Lomov]

If promises become a part of V8, we of course expect them to be quite usable on server-side too (node.js is our customer after all)

--

[Yutaka Hirano]

Thank you for your comments.

 

- please clarify your testing plans, both w.r.t. conformance and performance

We have LayoutTests in Blink and I plan to write tests something like them.

IIUC we can't write async tests with mjsunit. Maybe we will modify mjsunit.

For performance, currently I have no specific idea.

- as Jochen mentioned, let's work together to fit promises' needs into a larger work to unify threading between Blink and V8

Sure. Can you provide some pointers if any? 

- generally, it will be nice to have a design document describing promises implementation (maybe there is one already and I missed it?)

I see. I will write one.

[Erik Arvidsson]

On Mon, Oct 7, 2013 at 5:33 AM, Yutaka Hirano <yhi...@google.com> wrote:

Thank you for your comments.

 

- please clarify your testing plans, both w.r.t. conformance and performance

We have LayoutTests in Blink and I plan to write tests something like them.

IIUC we can't write async tests with mjsunit. Maybe we will modify mjsunit.

There are tests for Object.observe in V8 (both mjusunit and cctest) and I believe the cctests tests the timing and ordering of the callbacks.

--
erik

[Yutaka Hirano]

 

There are tests for Object.observe in V8 (both mjusunit and cctest) and I believe the cctests tests the timing and ordering of the callbacks.

Testing in cctest seems reasonable. Thank you.

[Yutaka Hirano]

I've written a design document for Promises.

https://docs.google.com/a/chromium.org/document/d/1_aw7DInk0V1eBl4OPaqXNMBgBPlN0hq-RC_OlteVkoY/edit#

It would be appreciated if you could give me some comments / suggestions.

Thanks,

[Andreas Rossberg]

Update on the V8/promise front:

After Yutaka started this thread, I looked at the promise spec in more
depth and proposed some structural simplifications. As proof of
concept for those I quickly banged together a JavaScript prototype
[1]. Most of that got adopted by Domenic in the latest draft (modulo
internal name changes) [2].

Since the prototype was already feature-complete, and a self-hosted V8
implementation shouldn't look much different, I simply went ahead and
turned it into a CL [3]. Comments are welcome.

Of course, this is just an initial implementation, and I'm happy that
Yutaka has agreed to take over from there, even though I was jumping a
bit ahead of his own initiative.

Thanks,
/Andreas

[1] https://github.com/rossberg-chromium/js-promise
[2] https://github.com/domenic/promises-unwrapping/blob/master/README.md
[3] https://codereview.chromium.org/64223010/

[Domenic Denicola]

Awesome to hear!

As of now, that changeset adds several non-standard methods and, more importantly, fails a plethora of tests among those tested in the promises-unwrapping spec repo. I'll put together a more detailed report this weekend. But I wanted to make sure the appropriate people were aware of these issues, and I couldn't figure out the code review interface.

[Andreas Rossberg]

On 15 November 2013 13:20, Domenic Denicola <dom...@domenicdenicola.com> wrote:
> As of now, that changeset adds several non-standard methods and, more importantly, fails a plethora of tests among those tested in the promises-unwrapping spec repo. I'll put together a more detailed report this weekend. But I wanted to make sure the appropriate people were aware of these issues, and I couldn't figure out the code review interface.

Great, yes, please share your findings. We definitely will need to
have a more extensive test suite, and adapting existing Blink tests as
well as tests from your repo is a high priority. This CL is just the
first step. I fully expect that the implementation still needs some
tweaking. (I will also try to keep the github prototype in sync if I
can.)

Thanks,
/Andreas