Intent to implement: V8 extras

[Domenic Denicola]

Over the last two weeks we’ve been working on a new feature designed for V8 embedders, called “V8 extras.” The intent is to allow embedders to write self-hosted (i.e. JavaScript) implementations of various features, with more power and less drawbacks than the existing V8 extensions mechanism. Notably, we are building on top of recent snapshotting work to ensure that the code for V8 extras is included in the snapshot, and so should not have negative impact on context startup time.

You can see a working, albeit in-progress, example of a V8 extra in this CL, which uses them to implement readable streams from the Streams Standard. General features on display include:

• The inclusion of the extras via the v8_extra_library_files GYP variable
• The use of V8 native functions, such as %CreatePrivateOwnSymbol, in the .js files (but see below)
• The use of the extrasExports object to export functions and values to the embedder. This object can be accessed through the V8 C++ API with v8::Context::GetExtrasExportsObject().

There are a number of changes we’re still working on implementing before we could comfortably say that this feature is ready:

• We do not want to allow extras direct access to V8 native functions, but instead only to a small number of pre-specified ones. The details on how to do this are still being worked out, but it will probably involve a slight change to the authoring format of the extras files, to become e.g. script whose completion value is a function that gets such a utility object passed in.
• We need a story for segregating “experimental” extras from shipping ones, similar to what is being done in V8 already for harmony features. Experimental extras cannot live in the snapshot, since they must be able to be turned off at runtime, while shipping ones will be compiled in.
• We eventually want to expose an easy way for the embedder to supply functions or values to the extras code. This is not actually needed for streams, but for example if we were to implement something like TextEncoder or URL as an extra, it would be crucial.

Overall though, we are quite excited about the possibilities this opens up, by allowing embedders a performant way to implement features in JavaScript.

Best,

Domenic Denicola
Jochen Eisinger
Yang Guo

[Kentaro Hara]

Is the V8 extras going to be used for features that can completely implemented on top of JavaScript and already existing DOM APIs? Or do you have a plan to make the V8 extras interact with C++ DOM somehow? (If so, I'm curious how you're going to implement the binding layer.)

--

Kentaro Hara, Tokyo, Japan

[Yang Guo]

The plan is to introduce a V8 API that takes an object template that implements the bindings via function templates. This object template is used to create a bindings object, which is exposed to the script. This way it can call into C++ via function templates. I'll make it work with the serializer so that deserialized code is hooked up correctly to that bindings object.

[Michael Hablich]

Hi Domenic, Jochen and Yang,

this sounds really cool. Can you please add a link to an accessible design documentation? Collaboration will be much easier via GDocs.

Thanks,

Michael

[Kentaro Hara]

This sounds pretty great, but I'm also curious about the relationship
to Blink-in-JS.

I'm curious about this as well -- in more general, I'm curious about how we're going to layer the web platform.

Here's my understanding; correct me if I'm wrong.

- V8 extras and Blink-in-JS are aiming at different goals.

- Blink-in-JS is aiming at implementing WebIDL features on top of existing Web APIs. Thus we don't want to add any "backdoor"s to the Web APIs, since those backdoors will break the layering philosophy of Blink-in-JS and make it harder to port the implementation to other vendors.

- V8 extras is not directly related to WebIDL and is a more intrusive way to implement any feature using JS (instead of C++). For example, you can implement streams etc in V8 extras. If the streams.js needs to interact with C++, you can just expose V8 APIs for the interactions and the binding layer to connect the V8 APIs with the C++ (e.g., V8Streams class that abstracts the V8 APIs etc). From the viewpoint of Blink, the feature implemented by V8 extras will just look like other features in V8 -- in other words, there are V8 APIs to interact with the feature and Blink can just use the V8 APIs through the binding layer. This is a layering technology inside Chromium and it is not planned to port the JS implementation to other vendors.

(I also want to see a design document of V8 extras.)

On Tue, May 12, 2015 at 8:43 PM, Philip Jägenstedt <phi...@opera.com> wrote:

This sounds pretty great, but I'm also curious about the relationship
to Blink-in-JS.

I poke at our <video controls> implementation in C++ from time to time
and it's just screaming out to be rewritten in JavaScript, so I'd like
to know if V8 extras might be useful for that. What's needed is a way
for C++ to hand a video element and an empty container to external
JavaScript code that would add controls to the container and hook up
the events.

> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

[Jochen Eisinger]

I agree that Blink-in-JS and V8 extras have different goals.

V8 extras is supposed to enable exactly what you describe without impacting the performance of the feature in a negative way (e.g., like a V8 extension that would incur additional costs for each new context due to compilation and execution).

You know that I disagree about Blink-in-JS's utility for implementing web platform features, so I won't repeat that here in detail again.

Design doc sounds indeed like a good idea. Domenic, you had an internal doc about streams + v8 extras. Mind brushing that up and making it public?

thanks

-jochen

--
--
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/d/optout.

[Domenic Denicola]

> (I also want to see a design document of V8 extras.)

Your wish is my command! Working on one at https://docs.google.com/document/d/1AT5-T0aHGp7Lt29vPWFr2-qG8r3l9CByyvKwEuA8Ec0/edit?usp=sharing ; got through most of the introductory/scope stuff and have a lot of TODOs for the technical side, but I plan to fill those in tonight/tomorrow.

[Kentaro Hara]

> (I also want to see a design document of V8 extras.)

Your wish is my command! Working on one at https://docs.google.com/document/d/1AT5-T0aHGp7Lt29vPWFr2-qG8r3l9CByyvKwEuA8Ec0/edit?usp=sharing ; got through most of the introductory/scope stuff and have a lot of TODOs for the technical side, but I plan to fill those in tonight/tomorrow.

Thanks for the doc! I'm a big fan of the V8 extras :)

[Domenic Denicola]

https://docs.google.com/document/d/1AT5-T0aHGp7Lt29vPWFr2-qG8r3l9CByyvKwEuA8Ec0/edit?usp=sharing is now complete, including sections on technical design, security considerations, and alternatives considered that were missing yesterday when I sent the previous message. Comments appreciated!