Re: JSBC: JavaScript Start-up Bytecode Cache
On 6/13/17 5:23 PM, Kris Maglione wrote: Yes and no. We do something similar to this for the module loader and subscript loader, but only for the entire compiled source, not for individual functions, and without any kind of lazy compilation. True. For
Changing .idl files
Hi, What must be considered when changing an XPIDL interface in a .idl file? As far as I know, it's the following. (1) Update browser C++ code that uses the interface. This is easy because the compiler will tell you the parts that need changing. (2) Update browser JS code that uses the interface. This is harder because it requires using grep or a similar tool to find all the occurrences. But it's usually not too bad. (3) Do extensions use it? If so, changing it probably isn't possible. This can be imperfectly determined by searching through addons/ in DXR. (4) Does Thunderbird use it? This is no longer a hard constraint, but is something to consider. Once Firefox 57 disallows all extensions other than Web Extension, I think (3) will no longer be relevant. In which case, once 57 is under development (August ~7th) it will be *much* easier to change XPIDL interfaces. (Although, if DevTools are moved its their own repository, that repo will have to be checked as well?) Is all that correct? Have I missed anything? Thanks. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JSBC: JavaScript Start-up Bytecode Cache
On Tue, Jun 13, 2017 at 12:10:58PM -0400, Boris Zbarsky wrote: > On 6/13/17 11:00 AM, Dirkjan Ochtman wrote: > > Has anyone thought about doing similar things for chrome JS? > > We've been doing fastload for chrome JS (and indeed for entire chrome XUL > documents, including their scripts) for 15+ years now, no? Back memory lane... Fastload is 16 years old according to bugzilla (bug 68045), but was removed 6 years ago (bug 654489) in favor of startupcache (bug 592943), which, BTW, we're not generating at build time anymore as of Firefox 55 (bug 1351071) (but we're still generating it at startup time). I don't remember what fastload was keeping around, but startupcache stores pre-parsed JS, but I'm not sure of the details, whether that's some AST or something else. Storing bytecode instead could still be a win. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JSBC: JavaScript Start-up Bytecode Cache
On 2017-06-13 4:36 PM, Chris Peterson wrote: Nicolas, when JSBC is enabled by default, should we change our test procedure for our various page load tests (Talos and Softvision's manual testing)? Since the first page load will be slower than subsequent page loads (as you noted in the bug [1]), should we throw away the first page load time or continue to average it with the subsequent page load times? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=900784#c72 For the aggregated Talos summary values we display and alert on in Perfherder, we already throw out the first few page loads in most (all?) tests. For example: https://wiki.mozilla.org/Buildbot/Talos/Tests#tp5 Will ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JSBC: JavaScript Start-up Bytecode Cache
On Tue, Jun 13, 2017 at 12:10:58PM -0400, Boris Zbarsky wrote: On 6/13/17 11:00 AM, Dirkjan Ochtman wrote: Has anyone thought about doing similar things for chrome JS? We've been doing fastload for chrome JS (and indeed for entire chrome XUL documents, including their scripts) for 15+ years now, no? Yes and no. We do something similar to this for the module loader and subscript loader, but only for the entire compiled source, not for individual functions, and without any kind of lazy compilation. For
Re: JSBC: JavaScript Start-up Bytecode Cache
Nicolas, when JSBC is enabled by default, should we change our test procedure for our various page load tests (Talos and Softvision's manual testing)? Since the first page load will be slower than subsequent page loads (as you noted in the bug [1]), should we throw away the first page load time or continue to average it with the subsequent page load times? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=900784#c72 chris On 6/13/17 2:50 AM, Nicolas B. Pierron wrote: The JavaScript Start-up Bytecode Cache⁰ is a project which aims at reducing the page load time by recording the bytecode generated during the last visits and by-pass the JavaScript parser. This project changes the way we process JavaScript script tags which are fetched from the network, and cached. After multiple visits¹, the bytecode would be encoded incrementally², as soon as the bytecode emitter generates it. Once we reached some idle time³, we save the content encoded incrementally as an alternate data on the cache⁴. The cache contains a compressed version of the source, the bytecode of functions which got executed during the start-up of the page, and all non-executed functions encoded as source indexes⁵. On follow-up visits the script loader would load the alternate data instead⁶ of the source, and decode the bytecode either off-thread⁷ or on the current-thread. This is expected to replace the syntax checker and the bytecode emitter for all recorded functions. This feature is currently pref-ed off and can be enabled by setting the following preferences in about:config⁸: - dom.script_loader.bytecode_cache.enabled = true - dom.script_loader.bytecode_cache.strategy = 0 For any issue caused by this optimization, filed it as a blocker of Bug 900784. In the upcoming days, I will add telemetry probes to better tune the heuristics¹ for the web and monitor the known sources of fallback and failures. In addition, I will request for a pref-experiment, such that we can get more data from nightly users. At the moment, I expect to enable this feature around mid-July. ⁰ https://bugzilla.mozilla.org/show_bug.cgi?id=900784 ¹ These are heuristics which would be customized by running a pref-experiment. (see https://bugzilla.mozilla.org/show_bug.cgi?id=1362114) ² We cannot do it off-thread, nor after the execution (see https://bugzilla.mozilla.org/show_bug.cgi?id=1316081) ³ Currently set to the next cycle after the processing of the OnLoad event. (see https://bugzilla.mozilla.org/show_bug.cgi?id=1372207) ⁴ Thanks to Valentin Gosu for his work and support on the alternate data interface as part of necko. (see https://bugzilla.mozilla.org/show_bug.cgi?id=1231565) ⁵ https://bugzilla.mozilla.org/show_bug.cgi?id=917996 ⁶ This forces us to store the compressed source as part of the encoded bytecode, but prevent additional round-trip between the parent and child processes. ⁷ https://bugzilla.mozilla.org/show_bug.cgi?id=1316078 ⁸ http://searchfox.org/mozilla-central/rev/d840ebd5858a61dbc1622487c1fab74ecf235e03/modules/libpref/init/all.js#212-233 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rationalising Linux audio backend support
I know, it's a pretty late answer but: My four Computers, running on Linux (OpenSuSE) are working fine with alsa from the beginning of alsa on. Now there is no need for a unneccessary intermediate layer named Pulseaudio in an fine working alsa-system. Numberless Tux-Users ignore pulse and pulse still doesn't had it's breakthrough till now... Since Firefox doesn't support alsa, i use at the moment seamonkey or palemoon. If they go the same way, there will be other browsers, who respect the users and do not ignore them. Bye Firefox. I use Tux since 2002 and i know, what i am writing about. Bye Michael ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JSBC: JavaScript Start-up Bytecode Cache
On 06/13/2017 03:59 PM, David Teller wrote: On 6/13/17 5:37 PM, Nicolas B. Pierron wrote: Also, the chrome files are stored in the jar file (If I recall correctly), and we might want to generate the bytecode ahead of time, such that users don't have to go through the encoding-phase. How large is the bytecode? With the current implementation, it depends on the quantity of functions which are executed. If there is no script executed at all, then we would mostly have the chunk-compressed UC2-encoded source. If all functions are used then we would have the size of the bytecode, which is roughly more than twice the size of the source. In addition, you would need the compressed source if we want to have toSource working properly, which is currently mandatory for some addons (but not for long). As for the JSBC, as this depends on the number of executed functions, I am adding telemetry probe to monitor the size of the source and the size of the encoded content such that I can have an idea of this ratio. -- Nicolas B. Pierron ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JSBC: JavaScript Start-up Bytecode Cache
On 6/13/17 11:00 AM, Dirkjan Ochtman wrote: Has anyone thought about doing similar things for chrome JS? We've been doing fastload for chrome JS (and indeed for entire chrome XUL documents, including their scripts) for 15+ years now, no? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JSBC: JavaScript Start-up Bytecode Cache
On 6/13/17 5:37 PM, Nicolas B. Pierron wrote: > Also, the chrome files are stored in the jar file (If I recall > correctly), and we might want to generate the bytecode ahead of time, > such that users don't have to go through the encoding-phase. How large is the bytecode? I suspect that if it's too large, we'll be okay with generating the bytecode on the user's computer. Cheers, David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JSBC: JavaScript Start-up Bytecode Cache
On 06/13/2017 03:00 PM, Dirkjan Ochtman wrote: On Jun 13, 2017 11:55, "Nicolas B. Pierron" wrote: The JavaScript Start-up Bytecode Cache⁰ is a project which aims at reducing the page load time by recording the bytecode generated during the last visits and by-pass the JavaScript parser. So this is about content JS only? Yes, this is for the Content JS only, unless we are using the script loader as well for Gecko resources. Has anyone thought about doing similar things for chrome JS? Yes, and this is already the case for some XUL functions. Also, if we want to do that for chrome resources, then I wonder how many functions are unused during the start-up of Firefox? - If only a few are unused, then we might just store the complete bytecode. - If a lot remain unused, then we might do the same as here. Also, the chrome files are stored in the jar file (If I recall correctly), and we might want to generate the bytecode ahead of time, such that users don't have to go through the encoding-phase. It would seem like that would actually be easier (since it's known to be immutable)? The Alternate Data interface is good to abstract over the eviction conditions. So, from the ScriptLoader point of view, this is exactly as-if we are manipulating immutable scripts. -- Nicolas B. Pierron ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JSBC: JavaScript Start-up Bytecode Cache
On Jun 13, 2017 11:55, "Nicolas B. Pierron" wrote: The JavaScript Start-up Bytecode Cache⁰ is a project which aims at reducing the page load time by recording the bytecode generated during the last visits and by-pass the JavaScript parser. So this is about content JS only? Has anyone thought about doing similar things for chrome JS? It would seem like that would actually be easier (since it's known to be immutable)? Cheers, Dirkjan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JSBC: JavaScript Start-up Bytecode Cache
On Tue, Jun 13, 2017 at 5:50 AM, Nicolas B. Pierron < nicolas.b.pier...@mozilla.com> wrote: > The JavaScript Start-up Bytecode Cache⁰ is a project which aims at > reducing the page load time by recording the bytecode generated during the > last visits and by-pass the JavaScript parser. > > This project changes the way we process JavaScript script tags which are > fetched from the network, and cached. After multiple visits¹, the bytecode > would be encoded incrementally², as soon as the bytecode emitter generates > it. Once we reached some idle time³, we save the content encoded > incrementally as an alternate data on the cache⁴. The cache contains a > compressed version of the source, the bytecode of functions which got > executed during the start-up of the page, and all non-executed functions > encoded as source indexes⁵. > > On follow-up visits the script loader would load the alternate data > instead⁶ of the source, and decode the bytecode either off-thread⁷ or on > the current-thread. This is expected to replace the syntax checker and the > bytecode emitter for all recorded functions. > Just an FYI for people following along at home: 1. We don't support this when loading worker scripts yet. 2. If a page script load is intercepted by a service worker then this optimization is effectively disabled. There are a number of follow-up bugs filed to fix those things, but its a non-trivial amount of work. Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
JSBC: JavaScript Start-up Bytecode Cache
The JavaScript Start-up Bytecode Cache⁰ is a project which aims at reducing the page load time by recording the bytecode generated during the last visits and by-pass the JavaScript parser. This project changes the way we process JavaScript script tags which are fetched from the network, and cached. After multiple visits¹, the bytecode would be encoded incrementally², as soon as the bytecode emitter generates it. Once we reached some idle time³, we save the content encoded incrementally as an alternate data on the cache⁴. The cache contains a compressed version of the source, the bytecode of functions which got executed during the start-up of the page, and all non-executed functions encoded as source indexes⁵. On follow-up visits the script loader would load the alternate data instead⁶ of the source, and decode the bytecode either off-thread⁷ or on the current-thread. This is expected to replace the syntax checker and the bytecode emitter for all recorded functions. This feature is currently pref-ed off and can be enabled by setting the following preferences in about:config⁸: - dom.script_loader.bytecode_cache.enabled = true - dom.script_loader.bytecode_cache.strategy = 0 For any issue caused by this optimization, filed it as a blocker of Bug 900784. In the upcoming days, I will add telemetry probes to better tune the heuristics¹ for the web and monitor the known sources of fallback and failures. In addition, I will request for a pref-experiment, such that we can get more data from nightly users. At the moment, I expect to enable this feature around mid-July. ⁰ https://bugzilla.mozilla.org/show_bug.cgi?id=900784 ¹ These are heuristics which would be customized by running a pref-experiment. (see https://bugzilla.mozilla.org/show_bug.cgi?id=1362114) ² We cannot do it off-thread, nor after the execution (see https://bugzilla.mozilla.org/show_bug.cgi?id=1316081) ³ Currently set to the next cycle after the processing of the OnLoad event. (see https://bugzilla.mozilla.org/show_bug.cgi?id=1372207) ⁴ Thanks to Valentin Gosu for his work and support on the alternate data interface as part of necko. (see https://bugzilla.mozilla.org/show_bug.cgi?id=1231565) ⁵ https://bugzilla.mozilla.org/show_bug.cgi?id=917996 ⁶ This forces us to store the compressed source as part of the encoded bytecode, but prevent additional round-trip between the parent and child processes. ⁷ https://bugzilla.mozilla.org/show_bug.cgi?id=1316078 ⁸ http://searchfox.org/mozilla-central/rev/d840ebd5858a61dbc1622487c1fab74ecf235e03/modules/libpref/init/all.js#212-233 -- Nicolas B. Pierron ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
