Adding new attributes to IDL to mark side-effect-free methods

[Erik Luo]

Hi platform-architecture-dev,

On the DevTools team, we're working on features that involve evaluating user-entered text in a safe manner.  We currently show previews for expressions evaluated in console upon enter, but also in popovers when the mouse hovers over an expression and debugger is paused.  Our goal is to accurately decide if an expression can be evaluated eagerly without accidentally modifying JS state, e.g. `x++`.

V8 provides us with whitelist-based side-effect checks, but we'd like to strengthen the logic by marking specific Blink functions as [pure] to indicate it "hasNoJSSideEffect".  When V8 is about to evaluate an embedder function with `hasSideEffect(function)`, it will simply check the function info for a flag.  This would let us know that `document.body.className` or `element.id`.

For reference, Firefox has similar IDL attributes [pure], [dependsOn], and [affects=Nothing], but their use cases seems to be for dead-code elimination.  Theirs also distinguishes between methods that affect DOM state.  I'm guessing this is for methods such as `element.offsetHeight`, which may affect layout.  For DevTools, our use case cares about JS-pure effects, so a distinction between DOM-pure and JS-pure isn't needed right now.

Could you please provide us your thoughts on this approach?  Maybe there are other teams interested in [pure] attributes too?  Feedback is welcome,

Erik

[Jeremy Roman]

On Fri, Mar 2, 2018 at 3:03 PM, 'Erik Luo' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

Hi platform-architecture-dev,

On the DevTools team, we're working on features that involve evaluating user-entered text in a safe manner.  We currently show previews for expressions evaluated in console upon enter, but also in popovers when the mouse hovers over an expression and debugger is paused.  Our goal is to accurately decide if an expression can be evaluated eagerly without accidentally modifying JS state, e.g. `x++`.

V8 provides us with whitelist-based side-effect checks, but we'd like to strengthen the logic by marking specific Blink functions as [pure] to indicate it "hasNoJSSideEffect".  When V8 is about to evaluate an embedder function with `hasSideEffect(function)`, it will simply check the function info for a flag.  This would let us know that `document.body.className` or `element.id`.

For reference, Firefox has similar IDL attributes [pure], [dependsOn], and [affects=Nothing], but their use cases seems to be for dead-code elimination.  Theirs also distinguishes between methods that affect DOM state.  I'm guessing this is for methods such as `element.offsetHeight`, which may affect layout.  For DevTools, our use case cares about JS-pure effects, so a distinction between DOM-pure and JS-pure isn't needed right now.

Be wary of layout, especially if/as layout worklet development ramps up. :)

Would you expect to annotate all such functions, or simply the most common ones used by developers? Annotating all of them sounds like a titanic effort, given how much WebIDL we have.

 

Could you please provide us your thoughts on this approach?  Maybe there are other teams interested in [pure] attributes too?  Feedback is welcome,

Last time we looked at it, I think it was for DCE, where we couldn't find evidence that it would materially matter on real applications.

 

Erik

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAB9tNk1S_Z9-53TYu%2BFqrwXGF0i0Zy4ekqegWebR5pKFKj5TjQ%40mail.gmail.com.

[Erik Luo]

Be wary of layout, especially if/as layout worklet development ramps up. :)

Ack!

 

Would you expect to annotate all such functions, or simply the most common ones used by developers? Annotating all of them sounds like a titanic effort, given how much WebIDL we have.

Annotating just the common ones fulfill our new cases, which need guaranteed safety.  This should be fine.

Existing features like the popover hover have been running with side effects for a long time now, and converting them to a side-effect free version would require a more comprehensive whitelist of IDLs.  I don't think that is worth it now, and we can consider other UX changes to address it.

[Kentaro Hara]

I'd support the proposal.

Maybe we could consider using [Pure] for dead-code elimination in the future (although it will just game micro-benchmarks like Dromaeo).

On Fri, Mar 2, 2018 at 2:12 PM, 'Erik Luo' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

Be wary of layout, especially if/as layout worklet development ramps up. :)

Ack!

 

Would you expect to annotate all such functions, or simply the most common ones used by developers? Annotating all of them sounds like a titanic effort, given how much WebIDL we have.

Annotating just the common ones fulfill our new cases, which need guaranteed safety.  This should be fine.

+1. It would be sufficient to annotate only popular IDL attributes :)

 

Existing features like the popover hover have been running with side effects for a long time now, and converting them to a side-effect free version would require a more comprehensive whitelist of IDLs.  I don't think that is worth it now, and we can consider other UX changes to address it.

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/e316bf7f-1e40-41b1-bf80-ecf1cd7bc48b%40chromium.org.

--

Kentaro Hara, Tokyo, Japan

[Yuki Shiino]

Generally I'd support the proposal, too, but I'm wondering how many kinds of IDL extended attributes will be introduced.  "No side effect" is not so trivial for me.  |element.id| has no side effect observable from JS code, but it's possible that it internally increments a use counter and/or histogram, which is a kind of side effect.  Depending on use cases, it's considered as "no side effect", but it's not always / not for all use cases.

So, I'm wondering if we need to introduce multiple versions of "no side effect" extended attributes.  Or are you planning to only handle purely pure cases (no JS observable side effect + no internal side effect)?

Cheers,

Yuki Shiino

2018年3月3日(土) 11:16 Kentaro Hara <har...@chromium.org>:

I'd support the proposal.

Maybe we could consider using [Pure] for dead-code elimination in the future (although it will just game micro-benchmarks like Dromaeo).

On Fri, Mar 2, 2018 at 2:12 PM, 'Erik Luo' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

Be wary of layout, especially if/as layout worklet development ramps up. :)

Ack!

 

Would you expect to annotate all such functions, or simply the most common ones used by developers? Annotating all of them sounds like a titanic effort, given how much WebIDL we have.

Annotating just the common ones fulfill our new cases, which need guaranteed safety.  This should be fine.

+1. It would be sufficient to annotate only popular IDL attributes :)

 

Existing features like the popover hover have been running with side effects for a long time now, and converting them to a side-effect free version would require a more comprehensive whitelist of IDLs.  I don't think that is worth it now, and we can consider other UX changes to address it.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/e316bf7f-1e40-41b1-bf80-ecf1cd7bc48b%40chromium.org.

--

Kentaro Hara, Tokyo, Japan

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jzG%3DzVYD9w%2BpdDdRM2hgv3zcLjrZ%2B55cuUyntSYWrs-MA%40mail.gmail.com.

[Erik Luo]

Incrementing usage counters is an interesting case, but triggering these sort of internal side effects is fine for us.  I cannot speak for other throwOnSideEffect users, however.

Our case requires a "DevTools-Pure" attribute, which covers (no JS observable side effect).  We also don't need to run any Network requests and can treat those as a side-effect, too.

On Monday, March 5, 2018 at 5:04:32 AM UTC-8, Yuki Shiino wrote:

Generally I'd support the proposal, too, but I'm wondering how many kinds of IDL extended attributes will be introduced.  "No side effect" is not so trivial for me.  |element.id| has no side effect observable from JS code, but it's possible that it internally increments a use counter and/or histogram, which is a kind of side effect.  Depending on use cases, it's considered as "no side effect", but it's not always / not for all use cases.

So, I'm wondering if we need to introduce multiple versions of "no side effect" extended attributes.  Or are you planning to only handle purely pure cases (no JS observable side effect + no internal side effect)?

Cheers,

Yuki Shiino

2018年3月3日(土) 11:16 Kentaro Hara <har...@chromium.org>:

I'd support the proposal.

Maybe we could consider using [Pure] for dead-code elimination in the future (although it will just game micro-benchmarks like Dromaeo).

On Fri, Mar 2, 2018 at 2:12 PM, 'Erik Luo' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

Be wary of layout, especially if/as layout worklet development ramps up. :)

Ack!

 

Would you expect to annotate all such functions, or simply the most common ones used by developers? Annotating all of them sounds like a titanic effort, given how much WebIDL we have.

Annotating just the common ones fulfill our new cases, which need guaranteed safety.  This should be fine.

+1. It would be sufficient to annotate only popular IDL attributes :)

 

Existing features like the popover hover have been running with side effects for a long time now, and converting them to a side-effect free version would require a more comprehensive whitelist of IDLs.  I don't think that is worth it now, and we can consider other UX changes to address it.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

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

To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/e316bf7f-1e40-41b1-bf80-ecf1cd7bc48b%40chromium.org.

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

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

[Erik Luo]

I am curious, though.  How easy would it be to start with a [Pure=JS] attribute, and extend the possible values in the future to [Pure=JS|DOMLayout|Internal] if needed?

[Kentaro Hara]

+1 to starting with [Pure=JS].

On Tue, Mar 6, 2018 at 5:14 AM, 'Erik Luo' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

I am curious, though.  How easy would it be to start with a [Pure=JS] attribute, and extend the possible values in the future to [Pure=JS|DOMLayout|Internal] if needed?

On Monday, March 5, 2018 at 11:53:34 AM UTC-8, Erik Luo wrote:

Incrementing usage counters is an interesting case, but triggering these sort of internal side effects is fine for us.  I cannot speak for other throwOnSideEffect users, however.

Our case requires a "DevTools-Pure" attribute, which covers (no JS observable side effect).  We also don't need to run any Network requests and can treat those as a side-effect, too.

On Monday, March 5, 2018 at 5:04:32 AM UTC-8, Yuki Shiino wrote:

Generally I'd support the proposal, too, but I'm wondering how many kinds of IDL extended attributes will be introduced.  "No side effect" is not so trivial for me.  |element.id| has no side effect observable from JS code, but it's possible that it internally increments a use counter and/or histogram, which is a kind of side effect.  Depending on use cases, it's considered as "no side effect", but it's not always / not for all use cases.

So, I'm wondering if we need to introduce multiple versions of "no side effect" extended attributes.  Or are you planning to only handle purely pure cases (no JS observable side effect + no internal side effect)?

Cheers,

Yuki Shiino

2018年3月3日(土) 11:16 Kentaro Hara <har...@chromium.org>:

I'd support the proposal.

Maybe we could consider using [Pure] for dead-code elimination in the future (although it will just game micro-benchmarks like Dromaeo).

On Fri, Mar 2, 2018 at 2:12 PM, 'Erik Luo' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

Be wary of layout, especially if/as layout worklet development ramps up. :)

Ack!

 

Would you expect to annotate all such functions, or simply the most common ones used by developers? Annotating all of them sounds like a titanic effort, given how much WebIDL we have.

Annotating just the common ones fulfill our new cases, which need guaranteed safety.  This should be fine.

+1. It would be sufficient to annotate only popular IDL attributes :)

 

Existing features like the popover hover have been running with side effects for a long time now, and converting them to a side-effect free version would require a more comprehensive whitelist of IDLs.  I don't think that is worth it now, and we can consider other UX changes to address it.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

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

To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/e316bf7f-1e40-41b1-bf80-ecf1cd7bc48b%40chromium.org.

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

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

To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jzG%3DzVYD9w%2BpdDdRM2hgv3zcLjrZ%2B55cuUyntSYWrs-MA%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/fa8fd259-f4bc-46d1-926d-0ee63aad2d3c%40chromium.org.

[Yuki Shiino]

It should be pretty easy to start with [Pure=JS] as long as its definition is clear, like no side effect observable from JS.

By the way, if I understand the purpose and expected usage correctly, [Affects=Nothing] in Firefox is what you want, right?  [Affects=Nothing] is clearer to me than [Pure=JS] where the word "pure" could be interpreted in many ways.  Is there any issue to simply copy [Affects=Nothing] from Firefox?

Anyway, the approach looks good to me.

Cheers,

Yuki Shiino

2018年3月6日(火) 9:31 Kentaro Hara <har...@chromium.org>:

+1 to starting with [Pure=JS].

On Tue, Mar 6, 2018 at 5:14 AM, 'Erik Luo' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

I am curious, though.  How easy would it be to start with a [Pure=JS] attribute, and extend the possible values in the future to [Pure=JS|DOMLayout|Internal] if needed?

On Monday, March 5, 2018 at 11:53:34 AM UTC-8, Erik Luo wrote:

Incrementing usage counters is an interesting case, but triggering these sort of internal side effects is fine for us.  I cannot speak for other throwOnSideEffect users, however.

Our case requires a "DevTools-Pure" attribute, which covers (no JS observable side effect).  We also don't need to run any Network requests and can treat those as a side-effect, too.

On Monday, March 5, 2018 at 5:04:32 AM UTC-8, Yuki Shiino wrote:

Generally I'd support the proposal, too, but I'm wondering how many kinds of IDL extended attributes will be introduced.  "No side effect" is not so trivial for me.  |element.id| has no side effect observable from JS code, but it's possible that it internally increments a use counter and/or histogram, which is a kind of side effect.  Depending on use cases, it's considered as "no side effect", but it's not always / not for all use cases.

So, I'm wondering if we need to introduce multiple versions of "no side effect" extended attributes.  Or are you planning to only handle purely pure cases (no JS observable side effect + no internal side effect)?

Cheers,

Yuki Shiino

2018年3月3日(土) 11:16 Kentaro Hara <har...@chromium.org>:

I'd support the proposal.

Maybe we could consider using [Pure] for dead-code elimination in the future (although it will just game micro-benchmarks like Dromaeo).

On Fri, Mar 2, 2018 at 2:12 PM, 'Erik Luo' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

Be wary of layout, especially if/as layout worklet development ramps up. :)

Ack!

 

Would you expect to annotate all such functions, or simply the most common ones used by developers? Annotating all of them sounds like a titanic effort, given how much WebIDL we have.

Annotating just the common ones fulfill our new cases, which need guaranteed safety.  This should be fine.

+1. It would be sufficient to annotate only popular IDL attributes :)

 

Existing features like the popover hover have been running with side effects for a long time now, and converting them to a side-effect free version would require a more comprehensive whitelist of IDLs.  I don't think that is worth it now, and we can consider other UX changes to address it.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.

To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/e316bf7f-1e40-41b1-bf80-ecf1cd7bc48b%40chromium.org.

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.

To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jzG%3DzVYD9w%2BpdDdRM2hgv3zcLjrZ%2B55cuUyntSYWrs-MA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.

To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/fa8fd259-f4bc-46d1-926d-0ee63aad2d3c%40chromium.org.

[Ian Clelland]

On Tue, Mar 6, 2018 at 3:04 AM 'Yuki Shiino' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

It should be pretty easy to start with [Pure=JS] as long as its definition is clear, like no side effect observable from JS.

By the way, if I understand the purpose and expected usage correctly, [Affects=Nothing] in Firefox is what you want, right?  [Affects=Nothing] is clearer to me than [Pure=JS] where the word "pure" could be interpreted in many ways.  Is there any issue to simply copy [Affects=Nothing] from Firefox?

+1 for consistency; that may make it easier to detect where we're diverging from other engines.

Also +markdittmer, who's been building up tooling to track interoperability based on published IDL files

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAN0uC_QvkqriuEdbHxycsa5tA-vQa%3DuKRxfU9_MC5BFX-mhSwA%40mail.gmail.com.

[Joshua Bell]

Just as a sanity check...

* Calling nearly any function exposed via Web IDL that takes arguments can have side effects due to the conversion from JS to IDL types (e.g. toString() may get called, or a dictionary's getters, etc). Are we describing just side effects on the other side of that boundary?

* Similarly, most operations that consumes a WebIDL "any" type will trigger such side effects by later processing, e.g. serialization. Are we counting those, even though they happen beyond the bindings layer? 

(There may be a mix of those cases, e.g. where the spec defines the type conversion but we do it outside the bindings layer for performance, or conversely where the spec defines an "any" but we perform the conversion in the bindings code itself.)

A concrete example: IDBFactory's cmp() operation, which takes two "any" values in WebIDL. The values are converted to spec-internal key records, triggering side effects during the conversion, but the operation is otherwise conceptually "pure".

On Tue, Mar 6, 2018 at 7:21 AM, Ian Clelland <icle...@chromium.org> wrote:

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

To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/e316bf7f-1e40-41b1-bf80-ecf1cd7bc48b%40chromium.org.

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

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

To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jzG%3DzVYD9w%2BpdDdRM2hgv3zcLjrZ%2B55cuUyntSYWrs-MA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

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

To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/fa8fd259-f4bc-46d1-926d-0ee63aad2d3c%40chromium.org.

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAN0uC_QvkqriuEdbHxycsa5tA-vQa%3DuKRxfU9_MC5BFX-mhSwA%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAK_TSX%2BPsiN8hvV9BwZMz4TTrPz8dOBr4gNdukdioh8FGV3OFw%40mail.gmail.com.

[Erik Luo]

These are great questions.  The Mozilla attribute only takes two values [Affects=Everything|Nothing].  This is actually too restrictive, not granular enough for the DevTools use case, which needs just the JS-pure part and not the DOM-pure part.

I'd like to diverge in order to mark properties whose only side effect is a style/layout update.

Benefits of diverging:

This would let DevTools evaluate operations that potentially trigger style/layout update

- `Element.getBoundingClientRect`

- `Element.offsetHeight`

Could boost autocomplete suggestions for these Console expressions:

- `element.getBoundingClientRect().` > x, y, width, height, etc

- `myCanvas.getContext("2d").` > fillRect(), rotate(), etc

- `window.getSelection().` > anchorNode, anchorOffset, etc

Mozilla's IDL does not mark these examples as [Pure]/[Affects=Nothing].  I think these benefits are worth pursuing for DevTools, but how can we achieve WebIDL consistency?

Approaches:

- Blink introduces [Pure=JS] and others browsers with [Pure] eventually adopt the `JS` attribute value

- Blink introduces [Affects=NoJS] and other browsers with [Affects] eventually adopt the `NoJS` attribute value

- Blink adds [Affects=Nothing] and does not address the layout cases mentioned above

I prefer the first or second one, which reuse attribute names from another browser IDL, but also encourages others to be more granular.

* Calling nearly any function exposed via Web IDL that takes arguments can have side effects due to the conversion from JS to IDL types (e.g. toString() may get called, or a dictionary's getters, etc). Are we describing just side effects on the other side of that boundary?

* Similarly, most operations that consumes a WebIDL "any" type will trigger such side effects by later processing, e.g. serialization. Are we counting those, even though they happen beyond the bindings layer? 

For DevTools, these cases may be fine to whitelist.  In general, only operations that are always non-JS-observable are [Pure].  I'm not sure that V8's no-side-effect scope applies to a toString() called from embedder functions.

yangguo@: If we know that an embedded function is safe, can no-side-effect scope detect side-effects in this case?  e.g. `document.querySelector({toString: () => {x = 1}})`

[Jeremy Roman]

On Tue, Mar 6, 2018 at 4:45 PM, 'Erik Luo' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

These are great questions.  The Mozilla attribute only takes two values [Affects=Everything|Nothing].  This is actually too restrictive, not granular enough for the DevTools use case, which needs just the JS-pure part and not the DOM-pure part.

I'd like to diverge in order to mark properties whose only side effect is a style/layout update.

Benefits of diverging:

This would let DevTools evaluate operations that potentially trigger style/layout update

- `Element.getBoundingClientRect`

- `Element.offsetHeight`

Could boost autocomplete suggestions for these Console expressions:

- `element.getBoundingClientRect().` > x, y, width, height, etc

- `myCanvas.getContext("2d").` > fillRect(), rotate(), etc

- `window.getSelection().` > anchorNode, anchorOffset, etc

Couldn't this be done regardless, by just assuming that it succeeds and produces the expected value? The first and third produce a predictable type if they succeed, and the second doesn't seem too bad (though DevTools would need to replicate the context type -> context interface map).

 

Mozilla's IDL does not mark these examples as [Pure]/[Affects=Nothing].  I think these benefits are worth pursuing for DevTools, but how can we achieve WebIDL consistency?

Approaches:

- Blink introduces [Pure=JS] and others browsers with [Pure] eventually adopt the `JS` attribute value

- Blink introduces [Affects=NoJS] and other browsers with [Affects] eventually adopt the `NoJS` attribute value

- Blink adds [Affects=Nothing] and does not address the layout cases mentioned above

I prefer the first or second one, which reuse attribute names from another browser IDL, but also encourages others to be more granular.

* Calling nearly any function exposed via Web IDL that takes arguments can have side effects due to the conversion from JS to IDL types (e.g. toString() may get called, or a dictionary's getters, etc). Are we describing just side effects on the other side of that boundary?

* Similarly, most operations that consumes a WebIDL "any" type will trigger such side effects by later processing, e.g. serialization. Are we counting those, even though they happen beyond the bindings layer? 

For DevTools, these cases may be fine to whitelist.  In general, only operations that are always non-JS-observable are [Pure].  I'm not sure that V8's no-side-effect scope applies to a toString() called from embedder functions.

yangguo@: If we know that an embedded function is safe, can no-side-effect scope detect side-effects in this case?  e.g. `document.querySelector({toString: () => {x = 1}})`

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/e1320787-f741-4cdf-baf3-0042c96eac0d%40chromium.org.

[Jeremy Roman]

On Tue, Mar 6, 2018 at 4:59 PM, Jeremy Roman <jbr...@chromium.org> wrote:

On Tue, Mar 6, 2018 at 4:45 PM, 'Erik Luo' via platform-architecture-dev <platform-architecture-dev@chromium.org> wrote:

These are great questions.  The Mozilla attribute only takes two values [Affects=Everything|Nothing].  This is actually too restrictive, not granular enough for the DevTools use case, which needs just the JS-pure part and not the DOM-pure part.

I'd like to diverge in order to mark properties whose only side effect is a style/layout update.

Benefits of diverging:

This would let DevTools evaluate operations that potentially trigger style/layout update

- `Element.getBoundingClientRect`

- `Element.offsetHeight`

Could boost autocomplete suggestions for these Console expressions:

- `element.getBoundingClientRect().` > x, y, width, height, etc

- `myCanvas.getContext("2d").` > fillRect(), rotate(), etc

- `window.getSelection().` > anchorNode, anchorOffset, etc

Couldn't this be done regardless, by just assuming that it succeeds and produces the expected value? The first and third produce a predictable type if they succeed, and the second doesn't seem too bad (though DevTools would need to replicate the context type -> context interface map).

(Also, getContext doesn't seem pure to me.)

 

Mozilla's IDL does not mark these examples as [Pure]/[Affects=Nothing].  I think these benefits are worth pursuing for DevTools, but how can we achieve WebIDL consistency?

Approaches:

- Blink introduces [Pure=JS] and others browsers with [Pure] eventually adopt the `JS` attribute value

- Blink introduces [Affects=NoJS] and other browsers with [Affects] eventually adopt the `NoJS` attribute value

- Blink adds [Affects=Nothing] and does not address the layout cases mentioned above

I prefer the first or second one, which reuse attribute names from another browser IDL, but also encourages others to be more granular.

* Calling nearly any function exposed via Web IDL that takes arguments can have side effects due to the conversion from JS to IDL types (e.g. toString() may get called, or a dictionary's getters, etc). Are we describing just side effects on the other side of that boundary?

* Similarly, most operations that consumes a WebIDL "any" type will trigger such side effects by later processing, e.g. serialization. Are we counting those, even though they happen beyond the bindings layer? 

For DevTools, these cases may be fine to whitelist.  In general, only operations that are always non-JS-observable are [Pure].  I'm not sure that V8's no-side-effect scope applies to a toString() called from embedder functions.

yangguo@: If we know that an embedded function is safe, can no-side-effect scope detect side-effects in this case?  e.g. `document.querySelector({toString: () => {x = 1}})`

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

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

To post to this group, send email to platform-architecture-dev@chromium.org.

[Erik Luo]

Couldn't this be done regardless, by just assuming that it succeeds and produces the expected value? The first and third produce a predictable type if they succeed, and the second doesn't seem too bad (though DevTools would need to replicate the context type -> context interface map).

Could you please elaborate?  Evaluating the string "element.getBoundingClientRect()" in V8 without checking beforehand might affect JS heap.  Unless V8 knows that it is one of many functions marked side-effect-free, we cannot run and check the result's type before ensuring safety.

 

(Also, getContext doesn't seem pure to me.)

I haven't checked, so it may not be :)   Are getContext() calls JS-observable?

[Kentaro Hara]

I think Josh is making a great point.

IIUC what Josh is saying is: it would be really hard to identify JS-side-effect-free functions, in the first place.

If V8 bindings call ToString() to convert an argument to a string, it may cause some side effect on JS because ToString() may be overridden and invoke any arbitrary JavaScript.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

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

To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/13d2e9e3-db95-4739-a1f9-0972b28ac046%40chromium.org.

[Jeremy Roman]

On Tue, Mar 6, 2018 at 7:07 PM, Kentaro Hara <har...@chromium.org> wrote:

I think Josh is making a great point.

IIUC what Josh is saying is: it would be really hard to identify JS-side-effect-free functions, in the first place.

If V8 bindings call ToString() to convert an argument to a string, it may cause some side effect on JS because ToString() may be overridden and invoke any arbitrary JavaScript.

Yes -- this DevTools logic would need to know what argument conversions imply and reason that those conversions are also side-effect-free for the given value.

 

On Wed, Mar 7, 2018 at 7:20 AM, 'Erik Luo' via platform-architecture-dev <platform-architecture-dev@chromium.org> wrote:

Couldn't this be done regardless, by just assuming that it succeeds and produces the expected value? The first and third produce a predictable type if they succeed, and the second doesn't seem too bad (though DevTools would need to replicate the context type -> context interface map).

Could you please elaborate?  Evaluating the string "element.getBoundingClientRect()" in V8 without checking beforehand might affect JS heap.  Unless V8 knows that it is one of many functions marked side-effect-free, we cannot run and check the result's type before ensuring safety.

Right, but I mean that if you know that you have the genuine getBoundingClientRect function (which you need to know to reason about its pureness), then you know from the WebIDL that it only returns DOMRect. So ISTM that you can provide the completions suitable for DOMRect, even without actually evaluating it.

(Also, getContext doesn't seem pure to me.)

I haven't checked, so it may not be :)   Are getContext() calls JS-observable?

Yes -- once you've created a context, you cannot get a context of a different type.

 

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

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

To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/13d2e9e3-db95-4739-a1f9-0972b28ac046%40chromium.org.

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwVmqth%3DjL4usAzX%2BEr73z52YF%3DOvJRfD8Pfmnu_exJ2g%40mail.gmail.com.

[Yang Guo]

The background to this is that V8 offers a side-effect free mode for running JavaScript tailored to DevTools. It checks on every call to a JS function whether the callee may have side effects by checking its compiled bytecode and intrinsics against a whitelist. The design doc is here. Erik wants to extend this whitelist to blink bindings.

The issue you mentioned with re-entering V8 for function calls, for example for ToString() is addressed. At the point of the call to the ToString implementation (monkey-patched or not), V8 checks whether it can have side effects, and aborts execution if it does. If that function calls to a second one with side effects, we catch it at that function call.

So the IDL attribute only has to state whether the binding in C++ can cause any JS-observable side effect, e.g. call v8::Object::Set. You don't have to worry about calls to JS functions.

Cheers,

Yang

On Wed, Mar 7, 2018 at 4:49 AM Jeremy Roman <jbr...@chromium.org> wrote:

On Tue, Mar 6, 2018 at 7:07 PM, Kentaro Hara <har...@chromium.org> wrote:

I think Josh is making a great point.

IIUC what Josh is saying is: it would be really hard to identify JS-side-effect-free functions, in the first place.

If V8 bindings call ToString() to convert an argument to a string, it may cause some side effect on JS because ToString() may be overridden and invoke any arbitrary JavaScript.

Yes -- this DevTools logic would need to know what argument conversions imply and reason that those conversions are also side-effect-free for the given value.

 

On Wed, Mar 7, 2018 at 7:20 AM, 'Erik Luo' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

Couldn't this be done regardless, by just assuming that it succeeds and produces the expected value? The first and third produce a predictable type if they succeed, and the second doesn't seem too bad (though DevTools would need to replicate the context type -> context interface map).

Could you please elaborate?  Evaluating the string "element.getBoundingClientRect()" in V8 without checking beforehand might affect JS heap.  Unless V8 knows that it is one of many functions marked side-effect-free, we cannot run and check the result's type before ensuring safety.

Right, but I mean that if you know that you have the genuine getBoundingClientRect function (which you need to know to reason about its pureness), then you know from the WebIDL that it only returns DOMRect. So ISTM that you can provide the completions suitable for DOMRect, even without actually evaluating it.

(Also, getContext doesn't seem pure to me.)

I haven't checked, so it may not be :)   Are getContext() calls JS-observable?

Yes -- once you've created a context, you cannot get a context of a different type.

 

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/13d2e9e3-db95-4739-a1f9-0972b28ac046%40chromium.org.

--

Kentaro Hara, Tokyo, Japan

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwVmqth%3DjL4usAzX%2BEr73z52YF%3DOvJRfD8Pfmnu_exJ2g%40mail.gmail.com.

--

•  Yang Guo  •  Google Germany GmbH  •  Erika-Mann-Str. 33  •  80636 Munich  •  yan...@google.com

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks.

[Yang Guo]

One thing to note: I'm a bit concerned about termination exceptions [0]. In side-effect free mode, when V8 detects possible side effect, it aborts using termination exception. The bindings code, if whitelisted and if it re-enters V8, needs to correctly handle exceptions.

Yang

[0] https://docs.google.com/document/d/1GJqM2bmAEc1pSZc5WT86L9-h5raBibqkiD2sxTfOYrA/edit

[Kentaro Hara]

My proposal would be:

- Start with JS-side-effect-free IDL attributes / operations using Yang's approach.

- Add [Affects=Nothing] to IDL attributes / operations one by one (rather than adding it to many random IDL attributes / operations). Before adding [Affects=Nothing], manually check that V8 APIs used in the binding code are properly handling exceptions. (If not, fix the V8 API usage.)

I'm assuming that # of IDL attributes / operations you want to support is less than e.g., 50.

Any thoughts?

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/13d2e9e3-db95-4739-a1f9-0972b28ac046%40chromium.org.

--

Kentaro Hara, Tokyo, Japan

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwVmqth%3DjL4usAzX%2BEr73z52YF%3DOvJRfD8Pfmnu_exJ2g%40mail.gmail.com.

--

•  Yang Guo  •  Google Germany GmbH  •  Erika-Mann-Str. 33  •  80636 Munich  •  yan...@google.com

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks.

--

•  Yang Guo  •  Google Germany GmbH  •  Erika-Mann-Str. 33  •  80636 Munich  •  yan...@google.com

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks.

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAFSTc_jqoxOW-xr84mJ4RyKbbg%2B8XZ4UKNcJva6JDHEUnzknNA%40mail.gmail.com.

[Yang Guo]

SGTM. +1 to adding bindings one by one, adding tests for every one, and fixing exception handling if necessary.

Yang

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/13d2e9e3-db95-4739-a1f9-0972b28ac046%40chromium.org.

--

Kentaro Hara, Tokyo, Japan

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwVmqth%3DjL4usAzX%2BEr73z52YF%3DOvJRfD8Pfmnu_exJ2g%40mail.gmail.com.

--

•  Yang Guo  •  Google Germany GmbH  •  Erika-Mann-Str. 33  •  80636 Munich  •  yan...@google.com

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks.

--

•  Yang Guo  •  Google Germany GmbH  •  Erika-Mann-Str. 33  •  80636 Munich  •  yan...@google.com

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAFSTc_jqoxOW-xr84mJ4RyKbbg%2B8XZ4UKNcJva6JDHEUnzknNA%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

--

[Erik Luo]

haraken@'s proposal SGTM too.  If we use [Affects=Nothing], I can avoid annotating attributes that affect layout for now (e.g. `offsetHeight`, `scrollTop`).  That way, we'll start out being consistent with Mozilla's IDL.

I'll have to be very careful, manually check for exception handling and lookout for argument conversions and other cases jsbell@ mentioned.

I'm assuming that # of IDL attributes / operations you want to support is less than e.g., 50.

Yes.  There's <50 common attributes and <5 operations I'd like to annotate.  I can put together a public doc to track overall status.

Right, but I mean that if you know that you have the genuine getBoundingClientRect function (which you need to know to reason about its pureness), then you know from the WebIDL that it only returns DOMRect. So ISTM that you can provide the completions suitable for DOMRect, even without actually evaluating it.

Ah yes, I see what you mean.  I like this idea, it's something that DevTools could do without any evaluation.  I'll explore this direction separately, as WebIDL info offers us alot more, e.g. getting native function arguments for autocomplete.

[Erik Luo]

To followup, here is a draft list of attributes/operations that would be useful to whitelist as side-effect-free for DevTools.

There's actually very few operations (12 now) that I'd like to verify+annotate.  Attributes make up the rest of the list!

I'd like to suggest that we start out marking only operations with [Affects=Nothing].  For attributes, I suggest we automatically set has_no_side_effect=true on all attribute getters, instead of manually whitelisting individual attributes.

This would allow us to experiment with our new features with a smaller imprint on the IDL files, and get us to a live experiment more quickly.  Also, it's easier to change 12 annotations in the future, rather than 65.

Would others comfortable with this?

[Kentaro Hara]

On Tue, Mar 13, 2018 at 12:58 AM, Erik Luo <lu...@google.com> wrote:

To followup, here is a draft list of attributes/operations that would be useful to whitelist as side-effect-free for DevTools.

There's actually very few operations (12 now) that I'd like to verify+annotate.  Attributes make up the rest of the list!

As far as I scan the list, it looks good to me :)

I'd like to suggest that we start out marking only operations with [Affects=Nothing].  For attributes, I suggest we automatically set has_no_side_effect=true on all attribute getters, instead of manually whitelisting individual attributes.

If you automatically set has_no_side_effect=true on all attribute getters, won't it end up with marking thousands of attributes with [Affects=Nothing]?

 

This would allow us to experiment with our new features with a smaller imprint on the IDL files, and get us to a live experiment more quickly.  Also, it's easier to change 12 annotations in the future, rather than 65.

Would others comfortable with this?

[Erik Luo]

If you automatically set has_no_side_effect=true on all attribute getters, won't it end up with marking thousands of attributes with [Affects=Nothing]?

Sorry, what I mean is: maybe we don't need to mark specific attribute getters with [Affects=Nothing] in the IDLs, and instead modify the place where we create v8::FunctionTemplates for them.

It seems like this involves changing just V8DOMConfiguration.cpp's InstallAccessorInternal().  Once V8 exposes a hasNoSideEffect flag for FunctionTemplate creation, InstallAccessorInternal() could call CreateAccessorFunctionOrTemplate(..., true /* hasNoSideEffect */) and v8::FunctionTemplate::New(..., true /* hasNoSideEffect */).

I need to check with V8 folks on the specifics of how this flag will be exposed, but it should allow us to mark attributes from FunctionTemplate creation.  Of course, this should only affect attribute getters, not setters.

[PhistucK]

offsetHeight and the like needs to be excluded here, right? Its getter causes layout.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/a093c1e8-e0f8-4e5b-81d7-af73c2b9d318%40chromium.org.

[Jeremy Roman]

You might also want to consider whether cases like MessageEvent.prototype.data (which triggers deserialization when first read) have side effects you would consider visible. I can't think of a case where it would cause you trouble, but it can construct a number of JS objects of various kinds.

On Tue, Mar 13, 2018 at 2:44 PM, PhistucK <phis...@gmail.com> wrote:

offsetHeight and the like needs to be excluded here, right? Its getter causes layout.

☆PhistucK

On Tue, Mar 13, 2018 at 8:25 PM, 'Erik Luo' via platform-architecture-dev <platform-architecture-dev@chromium.org> wrote:

If you automatically set has_no_side_effect=true on all attribute getters, won't it end up with marking thousands of attributes with [Affects=Nothing]?

Sorry, what I mean is: maybe we don't need to mark specific attribute getters with [Affects=Nothing] in the IDLs, and instead modify the place where we create v8::FunctionTemplates for them.

It seems like this involves changing just V8DOMConfiguration.cpp's InstallAccessorInternal().  Once V8 exposes a hasNoSideEffect flag for FunctionTemplate creation, InstallAccessorInternal() could call CreateAccessorFunctionOrTemplate(..., true /* hasNoSideEffect */) and v8::FunctionTemplate::New(..., true /* hasNoSideEffect */).

I need to check with V8 folks on the specifics of how this flag will be exposed, but it should allow us to mark attributes from FunctionTemplate creation.  Of course, this should only affect attribute getters, not setters.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

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

To post to this group, send email to platform-architecture-dev@chromium.org.

[Erik Luo]

You might also want to consider whether cases like MessageEvent.prototype.data (which triggers deserialization when first read) have side effects you would consider visible. I can't think of a case where it would cause you trouble, but it can construct a number of JS objects of various kinds.

Thanks for the case, I wasn't aware of attribute getters that created JS objects.  It seems that MessageEvent.p.data and others with [Custom] extended attribute may do manual operations on V8 objects.  If every getter attribute that manually touches V8 has a [Custom] attribute, it should suffice to exclude getters with [Custom] when automatically setting has_no_side_effect.

 

offsetHeight and the like needs to be excluded here, right? Its getter causes layout.

The getter does call layout, and this is important to consider.  The live evaluation feature we're working on is only concerned with JS-side-effects, not Layout/Style updates for now.  DevTools has its own experimental flags, so we can land it as an experiment while we evaluate/de-risk this concern.

There is already precedence for triggering layouts in DevTools.  When entering `document.body.offsetHeight.`, the Console evaluates the expression for autocomplete, today.

[Yuki Shiino]

2018年3月14日(水) 6:03 'Erik Luo' via platform-architecture-dev <platform-arc...@chromium.org>:

You might also want to consider whether cases like MessageEvent.prototype.data (which triggers deserialization when first read) have side effects you would consider visible. I can't think of a case where it would cause you trouble, but it can construct a number of JS objects of various kinds.

Thanks for the case, I wasn't aware of attribute getters that created JS objects.  It seems that MessageEvent.p.data and others with [Custom] extended attribute may do manual operations on V8 objects.  If every getter attribute that manually touches V8 has a [Custom] attribute, it should suffice to exclude getters with [Custom] when automatically setting has_no_side_effect.

No, please don't consider [Custom] like that.  Bindings team is working to reduce the number of [Custom] and ideally it will be zero someday (hopefully).  [Custom] has nothing to do with side effect.

I'd recommend to start the project with putting [Affects=Nothing] explicitly on attributes, too.  You only care about tens attributes so far, and it's the safest way.  It's easy to add more attributes and also it's easy to revert fully or partially.

Once the experiment goes well and it turns out that we need to annotate hundreds or thousand attributes, then we can switch the approach from whitelisting to blacklisting for example.

Cheers,

Yuki Shiino

 

offsetHeight and the like needs to be excluded here, right? Its getter causes layout.

The getter does call layout, and this is important to consider.  The live evaluation feature we're working on is only concerned with JS-side-effects, not Layout/Style updates for now.  DevTools has its own experimental flags, so we can land it as an experiment while we evaluate/de-risk this concern.

There is already precedence for triggering layouts in DevTools.  When entering `document.body.offsetHeight.`, the Console evaluates the expression for autocomplete, today.

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/78c1b6c3-15a4-4451-916b-17a148afc6b7%40chromium.org.

[Kentaro Hara]

On Wed, Mar 14, 2018 at 7:33 AM, 'Yuki Shiino' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

2018年3月14日(水) 6:03 'Erik Luo' via platform-architecture-dev <platform-architecture-dev@chromium.org>:

You might also want to consider whether cases like MessageEvent.prototype.data (which triggers deserialization when first read) have side effects you would consider visible. I can't think of a case where it would cause you trouble, but it can construct a number of JS objects of various kinds.

Thanks for the case, I wasn't aware of attribute getters that created JS objects.  It seems that MessageEvent.p.data and others with [Custom] extended attribute may do manual operations on V8 objects.  If every getter attribute that manually touches V8 has a [Custom] attribute, it should suffice to exclude getters with [Custom] when automatically setting has_no_side_effect.

No, please don't consider [Custom] like that.  Bindings team is working to reduce the number of [Custom] and ideally it will be zero someday (hopefully).  [Custom] has nothing to do with side effect.

I'd recommend to start the project with putting [Affects=Nothing] explicitly on attributes, too.  You only care about tens attributes so far, and it's the safest way.  It's easy to add more attributes and also it's easy to revert fully or partially.

+1

 

Once the experiment goes well and it turns out that we need to annotate hundreds or thousand attributes, then we can switch the approach from whitelisting to blacklisting for example.

Cheers,

Yuki Shiino

 

offsetHeight and the like needs to be excluded here, right? Its getter causes layout.

The getter does call layout, and this is important to consider.  The live evaluation feature we're working on is only concerned with JS-side-effects, not Layout/Style updates for now.  DevTools has its own experimental flags, so we can land it as an experiment while we evaluate/de-risk this concern.

There is already precedence for triggering layouts in DevTools.  When entering `document.body.offsetHeight.`, the Console evaluates the expression for autocomplete, today.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/78c1b6c3-15a4-4451-916b-17a148afc6b7%40chromium.org.

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAN0uC_RnaGfmwe1eb4hJvvKLNuKioOeJwK-80SQUf10j0HO7gg%40mail.gmail.com.