Intent to Ship: Explicit Compile Hints with Magic Comments

Marja Hölttä

unread,

Sep 30, 2024, 7:12:25 AMSep 30

(Sending this I2S as recommended by API owners, to continue the discussion about shipping this feature.)

Contact emails

Explainer

https://github.com/explainers-by-googlers/explicit-javascript-compile-hints-file-based/blob/main/README.md

Specification

https://explainers-by-googlers.github.io/explicit-javascript-compile-hints-file-based

Summary

Allow attaching information about which functions should be eager parsed & compiled in JavaScript files. The information will be encoded as magic comments. We'll first target launching the file-based explicit compile hints, and as a follow up, investigate selecting individual functions for eager compilation.

Blink component

Blink>JavaScript

TAG review

TAG review status

Pending

Chromium Trial Name

JavaScriptCompileHintsMagic

Link to origin trial feedback summary

https://google.qualtrics.com/jfe/form/SV_9SLyOGnTj2cwo0C

Origin Trial documentation link

https://docs.google.com/document/d/19xTAM4A75tz0xUq_velMzGA4JHEgXpyflUxXTcuNiyE/edit?usp=sharing

Risks

Interoperability and Compatibility

No interoperability / compatibility risks. Other browsers are likely to ignore the hints if they perceive they cannot benefit from them. Ignoring the hint is allowed behavior. We plan to make the hints generic though, so that other browsers can later start to support them too, e.g., if they implement background parsing / compilation.

Gecko: N/A (https://github.com/mozilla/standards-positions/issues/780)

WebKit: N/A (https://github.com/WebKit/standards-positions/issues/172)

Web developers: Positive Positive signals from partners who want to use compile hints to eager-compile core JS files.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Debuggability

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No

The feature doesn't trigger any functional changes and cannot be tested by WPT.

Flag name on chrome://flags

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/v8/issues/detail?id=13917

Estimated milestones

Origin trial desktop first	115
Origin trial desktop last	117
Origin trial extension 1 end milestone	131

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5100466238652416?gate=5172761812533248

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/BmN1Wus8V1s/m/3L2uU-wGAgAJ
Intent to Extend Experiment 1: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/mwZYYTBJ12g/m/HWsRCkuxAQAJ

This intent message was generated by Chrome Platform Status.

--

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian.

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

Yoav Weiss (@Shopify)

unread,

Oct 1, 2024, 2:31:49 AMOct 1

to blink-dev, Marja Hölttä, Leszek Swirski

Thanks for working on this! This is super interesting!!

On Monday, September 30, 2024 at 4:12:25 PM UTC+2 Marja Hölttä wrote:

(Sending this I2S as recommended by API owners, to continue the discussion about shipping this feature.)

Contact emails[email protected], leszeks@google.com

Explainerhttps://github.com/explainers-by-googlers/explicit-javascript-compile-hints-file-based/blob/main/README.md

Specificationhttps://explainers-by-googlers.github.io/explicit-javascript-compile-hints-file-based

We don't typically ship features with specs on personal or Google-owned repos.

I think it would be good to try and move this to an incubation venue (e.g. WICG).

This would be a better place from an IPR perspective (i.e. allow contributions outside of Google), and will help us validate that this is something that has at least some industry support.

Summary
Allow attaching information about which functions should be eager parsed & compiled in JavaScript files. The information will be encoded as magic comments. We'll first target launching the file-based explicit compile hints, and as a follow up, investigate selecting individual functions for eager compilation.

Blink componentBlink>JavaScript

TAG review

Did you file for a TAG review?

TAG review statusPending

Chromium Trial NameJavaScriptCompileHintsMagic

Link to origin trial feedback summaryhttps://google.qualtrics.com/jfe/form/SV_9SLyOGnTj2cwo0C

Origin Trial documentation linkhttps://docs.google.com/document/d/19xTAM4A75tz0xUq_velMzGA4JHEgXpyflUxXTcuNiyE/edit?usp=sharing

Risks

Interoperability and Compatibility
No interoperability / compatibility risks. Other browsers are likely to ignore the hints if they perceive they cannot benefit from them. Ignoring the hint is allowed behavior. We plan to make the hints generic though, so that other browsers can later start to support them too, e.g., if they implement background parsing / compilation.

Gecko: N/A (https://github.com/mozilla/standards-positions/issues/780)

WebKit: N/A (https://github.com/WebKit/standards-positions/issues/172)

Web developers: Positive Positive signals from partners who want to use compile hints to eager-compile core JS files.

Other signals:

WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Debuggability

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests?No
The feature doesn't trigger any functional changes and cannot be tested by WPT.

Flag name on chrome://flags

Finch feature nameNone

I *think* you can put JavaScriptCompileHintsMagicRuntime as the feature name.

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=13917

Estimated milestonesOrigin trial desktop first115Origin trial desktop last117Origin trial extension 1 end milestone131

Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5100466238652416?gate=5172761812533248

Links to previous Intent discussionsIntent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/BmN1Wus8V1s/m/3L2uU-wGAgAJ

Mike Taylor

unread,

Oct 1, 2024, 7:18:46 AMOct 1

to Marja Hölttä, Leszek Swirski, Yoav Weiss (@Shopify), blink-dev

Could you also please request the various Privacy, Security, Enterprise, etc. bits in your Chromestatus entry?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/95883282-a93f-4b2a-b34f-9bd4c401129en%40chromium.org.

Domenic Denicola

unread,

Oct 1, 2024, 5:15:55 PMOct 1

to Marja Hölttä, [email protected], Leszek Swirski

On Mon, Sep 30, 2024 at 11:12 PM 'Marja Hölttä' via blink-dev <[email protected]> wrote:

(Sending this I2S as recommended by API owners, to continue the discussion about shipping this feature.)

Contact emails
[email protected], [email protected]

Explainer
https://github.com/explainers-by-googlers/explicit-javascript-compile-hints-file-based/blob/main/README.md

Specification
https://explainers-by-googlers.github.io/explicit-javascript-compile-hints-file-based

Summary
Allow attaching information about which functions should be eager parsed & compiled in JavaScript files. The information will be encoded as magic comments. We'll first target launching the file-based explicit compile hints, and as a follow up, investigate selecting individual functions for eager compilation.

Blink component
Blink>JavaScript

TAG review

TAG review status
Pending

Chromium Trial Name
JavaScriptCompileHintsMagic

Link to origin trial feedback summary
https://google.qualtrics.com/jfe/form/SV_9SLyOGnTj2cwo0C

This link goes to a form asking me to provide feedback on the origin trial. Can you instead summarize the results of the origin trial, i.e. how many developers signed up, what kinds of benefits they saw, if they had any API feedback or requests, etc.?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAED6dUAN%3DzwdBsziegkniJi2hhF%3DVQ7xUk%2BdvB-6V%2B-TCTdiPg%40mail.gmail.com.

Jeffrey Yasskin

unread,

Oct 2, 2024, 8:56:08 AMOct 2

to Yoav Weiss (@Shopify), blink-dev, Marja Hölttä, Leszek Swirski

On Tue, Oct 1, 2024 at 2:32 AM Yoav Weiss (@Shopify) <[email protected]> wrote:

Thanks for working on this! This is super interesting!!

On Monday, September 30, 2024 at 4:12:25 PM UTC+2 Marja Hölttä wrote:
(Sending this I2S as recommended by API owners, to continue the discussion about shipping this feature.)
Contact emails[email protected], leszeks@google.com

Explainerhttps://github.com/explainers-by-googlers/explicit-javascript-compile-hints-file-based/blob/main/README.md

Specificationhttps://explainers-by-googlers.github.io/explicit-javascript-compile-hints-file-based

We don't typically ship features with specs on personal or Google-owned repos.
I think it would be good to try and move this to an incubation venue (e.g. WICG).
This would be a better place from an IPR perspective (i.e. allow contributions outside of Google), and will help us validate that this is something that has at least some industry support.

About a year ago, we had a thread asking about the standardization plans for this, and I suggested giving TC39 a PSA and trying to standardize this through the Web Perf WG. Can you point to any minutes from TC39 where you discussed this with them, and have you proposed this to a WG as https://www.chromium.org/blink/launching-features/#new-feature-prepare-to-ship:~:text=propose%20that%20the%20feature%20migrate%20to%20a%20working%20group requires?

Summary
Allow attaching information about which functions should be eager parsed & compiled in JavaScript files. The information will be encoded as magic comments. We'll first target launching the file-based explicit compile hints, and as a follow up, investigate selecting individual functions for eager compilation.

Blink componentBlink>JavaScript

TAG review

Did you file for a TAG review?

Yes, but the TAG hasn't commented: https://github.com/w3ctag/design-reviews/issues/947. It's architecturally interesting to convey performance hints via comments, where HTML uses attributes or sometimes elements, and CSS uses properties (e.g. will-change), but TC39 is probably the right venue to consider that.

Jeffrey

Marja Hölttä

unread,

Oct 3, 2024, 10:57:29 PMOct 3

to Jeffrey Yasskin, Yoav Weiss (@Shopify), blink-dev, Leszek Swirski

Thanks all! I'll reply to various things at once:

domenic@: thanks for pointing out the wrong link, that was a mistake. There's no Origin Trial feedback summary available, and the results we've gotten from Workspace devs are not publicly available.

jyasskin@: The TC39 info session is scheduled for the upcoming October meeting next week ( https://github.com/tc39/agendas/blob/main/2024/10.md )

Thanks for adding the TAG design review link, too. This is a TAG early design review, not a TAG specification review (I didn't find a way in Chromestatus to enter a link to the early design review; there's only a field for the specification review. Setting the state as "pending" is probably also not right, since that field is probably only about the specification review - fixed that now.)

We haven't proposed this to a WG yet, there was discussion about how we go about that and rbyers@ proposed moving that discussion to an I2S, so here it is.

miketaylr@: It's very likely that the privacy & security reviews will be very straightforward in comparison to the API owners approval. This is essentially a JavaScript feature (though, not a semantics changing one) so it doesn't have privacy implications. Security-wise, it's much less risky than other V8 features on average, so I don't expect much work to be coming from that direction either. That's why I kicked off the API owner discussion first, since that's the most interesting one. Would it be ok to do the privacy & security reviews only after this discussion has converged?

Domenic Denicola

unread,

Oct 3, 2024, 11:06:45 PMOct 3

to Marja Hölttä, Jeffrey Yasskin, Yoav Weiss (@Shopify), blink-dev, Leszek Swirski

On Fri, Oct 4, 2024 at 2:57 PM 'Marja Hölttä' via blink-dev <[email protected]> wrote:

Thanks all! I'll reply to various things at once:

domenic@: thanks for pointing out the wrong link, that was a mistake. There's no Origin Trial feedback summary available, and the results we've gotten from Workspace devs are not publicly available.

Can you work on making it public? We generally want to see some evidence that a feature is worth shipping and desired by web developers. This Google-internal doc explaining how to gather Origin Trial feedback from Google teams might be helpful.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAED6dUDrcx98wUWWAM4QZS5k%2BBv6_zST8_vMs2Oj5%2BSO6PYayw%40mail.gmail.com.

Noam Rosenthal

unread,

Oct 4, 2024, 2:15:29 AMOct 4

to Jeffrey Yasskin, Yoav Weiss (@Shopify), blink-dev, Marja Hölttä, Leszek Swirski

About a year ago, we had a thread asking about the standardization plans for this, and I suggested giving TC39 a PSA and trying to standardize this through the Web Perf WG. Can you point to any minutes from TC39 where you discussed this with them, and have you proposed this to a WG as https://www.chromium.org/blink/launching-features/#new-feature-prepare-to-ship:~:text=propose%20that%20the%20feature%20migrate%20to%20a%20working%20group requires?

I wasn't aware of the suggestion to mature this at WebPerfWG. Perhaps it's a good idea to give it a go....

I'm sure we can find an agenda slot at one of the Thursday meetings to present if you're interested (we can discuss this offline).

Mike Taylor

unread,

Oct 4, 2024, 6:12:12 AMOct 4

to Marja Hölttä, Jeffrey Yasskin, Yoav Weiss (@Shopify), blink-dev, Leszek Swirski

On 10/4/24 1:56 AM, 'Marja Hölttä' via blink-dev wrote:

miketaylr@: It's very likely that the privacy & security reviews will be very straightforward in comparison to the API owners approval. This is essentially a JavaScript feature (though, not a semantics changing one) so it doesn't have privacy implications. Security-wise, it's much less risky than other V8 features on average, so I don't expect much work to be coming from that direction either. That's why I kicked off the API owner discussion first, since that's the most interesting one. Would it be ok to do the privacy & security reviews only after this discussion has converged?

We ask that everyone request the various review gates before we give OWNERs approvals - but we don't block on the resolution of said reviews. Also, if you already have internal reviews (which is likely true given that you've already run an Origin Trial), you can just link to the internal launch bug and use the Request N/A button.

Rick Byers

unread,

Oct 4, 2024, 7:34:16 AMOct 4

to Mike Taylor, Marja Hölttä, Jeffrey Yasskin, Yoav Weiss (@Shopify), blink-dev, Leszek Swirski

The main reason I'm personally gung-ho on shipping this is that, as far as I can tell, it has extremely low interoperability and compatibility risk. This is just metadata that influences performance heuristics and (despite some risk) all browsers tweak performance heuristics all the time without necessarily having any public / transparent process for doing so. Even in the case of developer-influenced heuristics like PIFE, is there any precedent for following a standards track? This proposal seems strictly better in that regard in terms of plausibly becoming on a standards track someday as interest grows, so taking a step in that direction seems like a net positive to me. Marja, can you confirm that, should we get feedback later for adjusting the syntax and other details, we can easily change our implementation after shipping? Worst case we support both old and new formats for ~2 milestones while partners who really care about the perf wins they're seeing update, right?

Of course I agree that if we can meet the bar now for getting this into an IPR-protected venue, then absolutely we should. I know we've reached out to some non-Google developers to gauge interest and haven't yet found anyone interested in experimenting. It's good to poke on that a little more (eg. maybe this will turn up someone in the web perf community), but I don't think we should block indefinitely on it as long as we have evidence of clear user-benefit.

So in terms of demonstrating the benefit, Marja what data can you share about performance improvements that you've seen from properties who have tested this? From all our work on performance of native applications (like Chrome), I think it should be pretty obvious that PGO can lead to meaningful user-observable performance wins, but I do agree that we should be able to characterize those wins in a concrete public setting before shipping.

Rick

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/448934fc-6d9d-4e09-a728-64bf28201636%40chromium.org.

Yoav Weiss (@Shopify)

unread,

Oct 9, 2024, 1:53:38 AMOct 9

to blink-dev, Rick Byers, Marja Hölttä, Jeffrey Yasskin, Yoav Weiss, blink-dev, Leszek Swirski, Mike Taylor

Thanks for sending over the WICG proposal for this! I think there's now enough evidence of industry interest in this. That should enable y'all to move this to the WICG as a venue, which would resolve the IPR concerns.

On Friday, October 4, 2024 at 4:34:16 PM UTC+2 Rick Byers wrote:

The main reason I'm personally gung-ho on shipping this is that, as far as I can tell, it has extremely low interoperability and compatibility risk. This is just metadata that influences performance heuristics and (despite some risk) all browsers tweak performance heuristics all the time without necessarily having any public / transparent process for doing so. Even in the case of developer-influenced heuristics like PIFE, is there any precedent for following a standards track? This proposal seems strictly better in that regard in terms of plausibly becoming on a standards track someday as interest grows, so taking a step in that direction seems like a net positive to me. Marja, can you confirm that, should we get feedback later for adjusting the syntax and other details, we can easily change our implementation after shipping? Worst case we support both old and new formats for ~2 milestones while partners who really care about the perf wins they're seeing update, right?

Of course I agree that if we can meet the bar now for getting this into an IPR-protected venue, then absolutely we should. I know we've reached out to some non-Google developers to gauge interest and haven't yet found anyone interested in experimenting. It's good to poke on that a little more (eg. maybe this will turn up someone in the web perf community), but I don't think we should block indefinitely on it as long as we have evidence of clear user-benefit.

So in terms of demonstrating the benefit, Marja what data can you share about performance improvements that you've seen from properties who have tested this? From all our work on performance of native applications (like Chrome), I think it should be pretty obvious that PGO can lead to meaningful user-observable performance wins, but I do agree that we should be able to characterize those wins in a concrete public setting before shipping.

Rick

On Fri, Oct 4, 2024 at 9:12 AM Mike Taylor <[email protected]> wrote:

On 10/4/24 1:56 AM, 'Marja Hölttä' via blink-dev wrote:

miketaylr@: It's very likely that the privacy & security reviews will be very straightforward in comparison to the API owners approval. This is essentially a JavaScript feature (though, not a semantics changing one) so it doesn't have privacy implications. Security-wise, it's much less risky than other V8 features on average, so I don't expect much work to be coming from that direction either. That's why I kicked off the API owner discussion first, since that's the most interesting one. Would it be ok to do the privacy & security reviews only after this discussion has converged?

We ask that everyone request the various review gates before we give OWNERs approvals - but we don't block on the resolution of said reviews. Also, if you already have internal reviews (which is likely true given that you've already run an Origin Trial), you can just link to the internal launch bug and use the Request N/A button.

What Mike said. It's better to kick off these reviews at the start of the I2S, and API owners are unlikely to approve this without those reviews started.

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

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

Reply all

Reply to author

Forward