Replacing Blink-in-JS with V8 extras?

[Kentaro Hara]

Hi

As you know, Blink-in-JS has been a controversial feature in a couple of senses and it's not likely that we'll increase the use case in the future. When we want to implement a Blink feature in JS, it looks like that we prefer using V8 extra than Blink-in-JS.

Although V8 extra and Blink-in-JS are designed with a bit different assumptions about performance/security/intrusiveness, but they are basically doing similar things (i.e., a mechanism to implement Blink features in JS). Would it be possible to replace existing Blink-in-JS with V8 extras? Specifically, would it be possible to replace marquee-in-JS and XMLTreeViewer-in-JS with V8 extras?

--

Kentaro Hara, Tokyo, Japan

[Elliott Sprehn]

I'd like to discuss this further in a meeting...

My questions are why is the tree viewer blink in JS? It seems like it could just be plain JS in the page, at worst just plain JS in an extension world. No extra private script system should be needed.

I'd like to also consider moving marquee back to C++.

- E

[Kentaro Hara]

Right, and that is exactly what the V8 extra does (run the plain JS in the same context as the main page). 

I'd like to also consider moving marquee back to C++.

- E

[Jochen Eisinger]

I don't think V8 extras is a good fit for what Blink-in-JS is currently being used for. V8 extras are designed for JS libraries such as Streams or URL that we want to have in every context.

I agree with Elliott - other features like FTP directory listing are also implemented in regular javascript executed in the main world.

As for <marquee>, moving this to C++ without putting extra cost on the existing layout engine would be a good test for custom layout (or at least for the API it exposes), no?

[Kentaro Hara]

On Mon, Feb 29, 2016 at 4:50 PM, Jochen Eisinger <joc...@chromium.org> wrote:

I don't think V8 extras is a good fit for what Blink-in-JS is currently being used for. V8 extras are designed for JS libraries such as Streams or URL that we want to have in every context.

What are differences between Streams, URL, DOMPoint/DOMMatrix, XMLTreeViewer and marquee? I want to understand for what kind of features V8 extras should be used and should not be used.

[Jochen Eisinger]

Streams and URLs are defined as pure JS libraries, and as such e.g. also available to the proxy autoconfig scripts, or inside PDFium to PDF pages.

DOMPoint & DOMMatrix are purely POD. You could argue that making them available to all contexts is a bit odd, but won't hurt.

Why would we want to inject the XMLTreeViewer into every single context (given it's probably close to zero usage...)?

[Kentaro Hara]

DOMPoint & DOMMatrix are purely POD. You could argue that making them available to all contexts is a bit odd, but won't hurt.

Per the discussion in this CL, it looks like that people want to use V8 extras for DOMPoint/DOMMatrix to bypass the (slow) C++ binding layer. Is this an expected usage of V8 extras?

Why would we want to inject the XMLTreeViewer into every single context (given it's probably close to zero usage...)?

No strong reason. I was thinking that V8 extras is a generalized mechanism to run JavaScript in a specified context, so it would make sense to just move XMLTreeViewer to V8 extra (regardless of the usage).

Is there any cost in installing V8 extra in a context? Or more generally, what's the criteria where we should use V8 extra and we shouldn't?

[Jochen Eisinger]

On Mon, Feb 29, 2016 at 9:11 AM Kentaro Hara <har...@chromium.org> wrote:

DOMPoint & DOMMatrix are purely POD. You could argue that making them available to all contexts is a bit odd, but won't hurt.

Per the discussion in this CL, it looks like that people want to use V8 extras for DOMPoint/DOMMatrix to bypass the (slow) C++ binding layer. Is this an expected usage of V8 extras?

that sounds like a very poor reason. I'd rather spend energy on making our C++ binding layer as fast as JS.

 

Why would we want to inject the XMLTreeViewer into every single context (given it's probably close to zero usage...)?

No strong reason. I was thinking that V8 extras is a generalized mechanism to run JavaScript in a specified context, so it would make sense to just move XMLTreeViewer to V8 extra (regardless of the usage).

Is there any cost in installing V8 extra in a context? Or more generally, what's the criteria where we should use V8 extra and we shouldn't?

You can't not install V8 extras in a context. V8 extras are part of the snapshot, so every context gets them.

I'd propose the following criterium: V8 extras should be used for stuff where you think "Maybe I should bring this to TC39, but maybe they'll push back because it's not a core language feature".

[Kentaro Hara]

On Mon, Feb 29, 2016 at 5:21 PM, Jochen Eisinger <joc...@chromium.org> wrote:

On Mon, Feb 29, 2016 at 9:11 AM Kentaro Hara <har...@chromium.org> wrote:

DOMPoint & DOMMatrix are purely POD. You could argue that making them available to all contexts is a bit odd, but won't hurt.

Per the discussion in this CL, it looks like that people want to use V8 extras for DOMPoint/DOMMatrix to bypass the (slow) C++ binding layer. Is this an expected usage of V8 extras?

that sounds like a very poor reason. I'd rather spend energy on making our C++ binding layer as fast as JS.

 

Why would we want to inject the XMLTreeViewer into every single context (given it's probably close to zero usage...)?

No strong reason. I was thinking that V8 extras is a generalized mechanism to run JavaScript in a specified context, so it would make sense to just move XMLTreeViewer to V8 extra (regardless of the usage).

Is there any cost in installing V8 extra in a context? Or more generally, what's the criteria where we should use V8 extra and we shouldn't?

You can't not install V8 extras in a context. V8 extras are part of the snapshot, so every context gets them.

I'd propose the following criterium: V8 extras should be used for stuff where you think "Maybe I should bring this to TC39, but maybe they'll push back because it's not a core language feature".

Thanks for the clarification! That's interesting :)

A couple of questions:

- "Maybe I should bring this to TC39, but maybe they'll push back because it's not a core language feature" sounds like it's not yet a well-established feature, which implies that the usage is still low. Does it make sense to put such a low-usage feature into a v8 snapshot (and thus put it to every context)?

- I think it's an interesting idea to use V8 extras to bypass the overhead of the C++ binding layer (it's a kind of a generalized version of the fast DOM accessor; i.e., it can allow V8 to access DOM attributes/methods without leaving the JIT code). I understand that the current V8 extras are not suitable for the purpose because it's contained in the snapshot, but do you think that the idea of bypassing the C++ binding layer is worth investigating (if people on the DOMMatrix CL prove that V8 extras is a clear performance win for the matrix multiplication)?

[Jochen Eisinger]

On Mon, Feb 29, 2016 at 9:49 AM Kentaro Hara <har...@chromium.org> wrote:

On Mon, Feb 29, 2016 at 5:21 PM, Jochen Eisinger <joc...@chromium.org> wrote:

On Mon, Feb 29, 2016 at 9:11 AM Kentaro Hara <har...@chromium.org> wrote:

DOMPoint & DOMMatrix are purely POD. You could argue that making them available to all contexts is a bit odd, but won't hurt.

Per the discussion in this CL, it looks like that people want to use V8 extras for DOMPoint/DOMMatrix to bypass the (slow) C++ binding layer. Is this an expected usage of V8 extras?

that sounds like a very poor reason. I'd rather spend energy on making our C++ binding layer as fast as JS.

 

Why would we want to inject the XMLTreeViewer into every single context (given it's probably close to zero usage...)?

No strong reason. I was thinking that V8 extras is a generalized mechanism to run JavaScript in a specified context, so it would make sense to just move XMLTreeViewer to V8 extra (regardless of the usage).

Is there any cost in installing V8 extra in a context? Or more generally, what's the criteria where we should use V8 extra and we shouldn't?

You can't not install V8 extras in a context. V8 extras are part of the snapshot, so every context gets them.

I'd propose the following criterium: V8 extras should be used for stuff where you think "Maybe I should bring this to TC39, but maybe they'll push back because it's not a core language feature".

Thanks for the clarification! That's interesting :)

A couple of questions:

- "Maybe I should bring this to TC39, but maybe they'll push back because it's not a core language feature" sounds like it's not yet a well-established feature, which implies that the usage is still low. Does it make sense to put such a low-usage feature into a v8 snapshot (and thus put it to every context)?

It's not about being established or not, and we want streams and url in every context.

This is actually what happened with the streams API - it's a pure JS thing, so whatwg was hesitant to spec this - for fetch, they just need any streams API, there are no specific requirements.

For TC39, however, streams is purely syntactic sugar, so they didn't want to spec it either.

 

- I think it's an interesting idea to use V8 extras to bypass the overhead of the C++ binding layer (it's a kind of a generalized version of the fast DOM accessor; i.e., it can allow V8 to access DOM attributes/methods without leaving the JIT code). I understand that the current V8 extras are not suitable for the purpose because it's contained in the snapshot, but do you think that the idea of bypassing the C++ binding layer is worth investigating (if people on the DOMMatrix CL prove that V8 extras is a clear performance win for the matrix multiplication)?

In general, using JS for things that can be expressed entirely in JS is an option. We just need to be aware of the tradeoffs:

- If something is JS, a web page can intercept all of its behaviors or modify it to its likening.

- that also implies that it is super easy to leak privileged APIs (our friends from Chrome extensions demonstrate that on a weekly basis).

- we can't do things like enforcing a signature (those all rely on the non-JS visible function template hierarchy)

- all things JS are context bound, so they can't be shared cross contexts, and we have to set them up in every context (which is fast when we use the snapshot, but also not free).

hth

-jochen

[Kentaro Hara]

On Mon, Feb 29, 2016 at 6:04 PM, Jochen Eisinger <joc...@chromium.org> wrote:

On Mon, Feb 29, 2016 at 9:49 AM Kentaro Hara <har...@chromium.org> wrote:

On Mon, Feb 29, 2016 at 5:21 PM, Jochen Eisinger <joc...@chromium.org> wrote:

On Mon, Feb 29, 2016 at 9:11 AM Kentaro Hara <har...@chromium.org> wrote:

DOMPoint & DOMMatrix are purely POD. You could argue that making them available to all contexts is a bit odd, but won't hurt.

Per the discussion in this CL, it looks like that people want to use V8 extras for DOMPoint/DOMMatrix to bypass the (slow) C++ binding layer. Is this an expected usage of V8 extras?

that sounds like a very poor reason. I'd rather spend energy on making our C++ binding layer as fast as JS.

 

Why would we want to inject the XMLTreeViewer into every single context (given it's probably close to zero usage...)?

No strong reason. I was thinking that V8 extras is a generalized mechanism to run JavaScript in a specified context, so it would make sense to just move XMLTreeViewer to V8 extra (regardless of the usage).

Is there any cost in installing V8 extra in a context? Or more generally, what's the criteria where we should use V8 extra and we shouldn't?

You can't not install V8 extras in a context. V8 extras are part of the snapshot, so every context gets them.

I'd propose the following criterium: V8 extras should be used for stuff where you think "Maybe I should bring this to TC39, but maybe they'll push back because it's not a core language feature".

Thanks for the clarification! That's interesting :)

A couple of questions:

- "Maybe I should bring this to TC39, but maybe they'll push back because it's not a core language feature" sounds like it's not yet a well-established feature, which implies that the usage is still low. Does it make sense to put such a low-usage feature into a v8 snapshot (and thus put it to every context)?

It's not about being established or not, and we want streams and url in every context.

This is actually what happened with the streams API - it's a pure JS thing, so whatwg was hesitant to spec this - for fetch, they just need any streams API, there are no specific requirements.

For TC39, however, streams is purely syntactic sugar, so they didn't want to spec it either.

Thanks for the contexts. This makes sense.

[Domenic Denicola]

It does sound like we need a clearer document on when it's appropriate to use V8 extras. I have given my opinions in https://codereview.chromium.org/1709003002/#msg42. We can keep that debate about that CL over in the CL though.

Regarding XMLTreeViewer and HTMLMarqueeElement, I do not think V8 extras are a great fit for either of those. They are not very standalone, and interact with a lot of the engine's infrastructure.

It is possible that in some cases something might be so much easier in JavaScript than C++, that we want to use JS for part of it. My understanding is that this was somewhat the case for HTMLMarqueeElement's animations. In that case a possible solution is to use a V8 extras function (which is not web exposed through global, but just C++-exposed through bindings) to do that logic, and then call it from the rest of the C++ implementation, passing in the necessary objects for it to do its work. But I imagine that might also be controversial.