Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit
Status update #3: It seems like with PGO disabled for all of the above modules, we've now decreased the linker max vmem size by about 500MB, which is nice. There is one PGO build bustage https://tbpl.mozilla.org/php/getParsedLog.php?id=19006659tree=Mozilla-Inbound which has been re-triggered, and I think we should wait to make sure that it goes green, but then we should be able to reopen mozilla-inbound temporarily, with mozilla-central following when we merge inbound to central the next time. We should get the results of the re-triggered build in about two hours. Stay tuned! Cheers, -- Ehsan http://ehsanakhgari.org/ On Mon, Jan 21, 2013 at 11:32 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: Second status update: The numbers from disabling PGO on image, accessible and webrtc are in, and the linker max vmem size is down by only ~200MB, which is quite disappointing, especially since according to Randell, putting webrtc outside of libxul should buy us something around 600MB... So, as desparate times require desparate measures, I went ahead and disabled PGO on the following components as well: rdf (the original patch there busted the tree so I backd it out), editor, svg, mathml, xslt, embedding, storage, and the old HTML parser. I will not be awake long enough tonight to see what the progress would look like, but those interested can follow along here: https://tbpl.mozilla.org/?tree=Mozilla-Inboundjobname=WINNT%205.2%20.*%20pgo-build . I'm planning to keep the tree APPROVAL REQUIRED for now. I will re-evaluate the situation tomorrow, but I do expect that we will be able to temporarily reopen the tree tomorrow. In the mean time, if you can think about more components which will not be causing a big performance problem by disabling PGO on them, please file a bug and make it block bug 832992 (and even better, copy a file like this to their top-level directory to disable PGO on them: https://hg.mozilla.org/integration/mozilla-inbound/file/357b9a855e10/rdf/defs.mk ). Thanks! -- Ehsan http://ehsanakhgari.org/ On Mon, Jan 21, 2013 at 5:36 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: Status update: we have landed three patches on mozilla-inbound which disable PGO on the following directories (rdf/, image/ and accessible/) and I have triggered PGO builds on top of them to see how much they can shave off of the linker's vmem usage. Randel is also working on taking some webrtc code out of libxul in the mean time. If all of this proves to be ineffective, we can look into de-PGO-ing more code. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit
On Tue, Jan 22, 2013 at 7:35 AM, Mike Hommey m...@glandium.org wrote: On Tue, Jan 22, 2013 at 01:30:50PM +0100, Mike Hommey wrote: On Mon, Jan 21, 2013 at 11:32:34PM -0500, Ehsan Akhgari wrote: Second status update: The numbers from disabling PGO on image, accessible and webrtc are in, and the linker max vmem size is down by only ~200MB, which is quite disappointing, especially since according to Randell, putting webrtc outside of libxul should buy us something around 600MB... I doubt this is true. Since I was doing windows PGO builds for something else, I figured I'd try --disable-webgl. Err, --disable-webrtc. The build failed with a different internal compiler error (reliably, btw, which makes me wonder if try uses the same msvc version) and linker max vsize was around 37 (the changeset pushed to try being before any PGO disabling) Yes, Randell just confirmed this on IRC. It seems like the 600MB number was incorrect. Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit
How are the perf numbers looking? One of the reasons for asking is that I expect RDF to be part of the startup and window-open codepaths, at least. I'm not overly concerned, but wanted to make sure we look. Axel On 22.01.13 15:06, Ehsan Akhgari wrote: Status update #3: It seems like with PGO disabled for all of the above modules, we've now decreased the linker max vmem size by about 500MB, which is nice. There is one PGO build bustage https://tbpl.mozilla.org/php/getParsedLog.php?id=19006659tree=Mozilla-Inbound which has been re-triggered, and I think we should wait to make sure that it goes green, but then we should be able to reopen mozilla-inbound temporarily, with mozilla-central following when we merge inbound to central the next time. We should get the results of the re-triggered build in about two hours. Stay tuned! Cheers, -- Ehsan http://ehsanakhgari.org/ On Mon, Jan 21, 2013 at 11:32 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: Second status update: The numbers from disabling PGO on image, accessible and webrtc are in, and the linker max vmem size is down by only ~200MB, which is quite disappointing, especially since according to Randell, putting webrtc outside of libxul should buy us something around 600MB... So, as desparate times require desparate measures, I went ahead and disabled PGO on the following components as well: rdf (the original patch there busted the tree so I backd it out), editor, svg, mathml, xslt, embedding, storage, and the old HTML parser. I will not be awake long enough tonight to see what the progress would look like, but those interested can follow along here: https://tbpl.mozilla.org/?tree=Mozilla-Inboundjobname=WINNT%205.2%20.*%20pgo-build . I'm planning to keep the tree APPROVAL REQUIRED for now. I will re-evaluate the situation tomorrow, but I do expect that we will be able to temporarily reopen the tree tomorrow. In the mean time, if you can think about more components which will not be causing a big performance problem by disabling PGO on them, please file a bug and make it block bug 832992 (and even better, copy a file like this to their top-level directory to disable PGO on them: https://hg.mozilla.org/integration/mozilla-inbound/file/357b9a855e10/rdf/defs.mk ). Thanks! -- Ehsan http://ehsanakhgari.org/ On Mon, Jan 21, 2013 at 5:36 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: Status update: we have landed three patches on mozilla-inbound which disable PGO on the following directories (rdf/, image/ and accessible/) and I have triggered PGO builds on top of them to see how much they can shave off of the linker's vmem usage. Randel is also working on taking some webrtc code out of libxul in the mean time. If all of this proves to be ineffective, we can look into de-PGO-ing more code. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit
On 1/22/2013 9:28 AM, Axel Hecht wrote: How are the perf numbers looking? One of the reasons for asking is that I expect RDF to be part of the startup and window-open codepaths, at least. I would not expect PGO to optimize any of the RDF code for speed, even if they were in the startup codepaths. Boy howdy do we need to get RDF out of the tree, though! --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit
On 22/01/2013 15:36, Benjamin Smedberg wrote: On 1/22/2013 9:28 AM, Axel Hecht wrote: How are the perf numbers looking? One of the reasons for asking is that I expect RDF to be part of the startup and window-open codepaths, at least. I would not expect PGO to optimize any of the RDF code for speed, even if they were in the startup codepaths. Boy howdy do we need to get RDF out of the tree, though! --BDS I honestly have the same concerns regarding Storage, unfortunately we don't have data to tell if disabling PGO on it will affect its many consumers or not, apart the few talos measures :( It's possible those won't be affected cause sqlite is built separately and storage just wraps it, but there's no way to tell if, for example, the awesomebar or startup may end up being slower until we get enough telemetry. -m ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit
On 2013-01-22 9:45 AM, Marco Bonardo wrote: On 22/01/2013 15:36, Benjamin Smedberg wrote: On 1/22/2013 9:28 AM, Axel Hecht wrote: How are the perf numbers looking? One of the reasons for asking is that I expect RDF to be part of the startup and window-open codepaths, at least. I would not expect PGO to optimize any of the RDF code for speed, even if they were in the startup codepaths. Boy howdy do we need to get RDF out of the tree, though! --BDS I honestly have the same concerns regarding Storage, unfortunately we don't have data to tell if disabling PGO on it will affect its many consumers or not, apart the few talos measures :( It's possible those won't be affected cause sqlite is built separately and storage just wraps it, but there's no way to tell if, for example, the awesomebar or startup may end up being slower until we get enough telemetry. Once we determine that disabling PGO on storage actually regresses the performance, we can re-enable it. But note that unless a given code path is examined throughout the profiling phase of a PGO build, PGO will probably have negligible effect on it, if any. The PGO compiler looks for hot code paths and tries to optimize those, so for example if the awesomebar doesn't get examined during the profiling (which it isn't), it is extremely unlikely that turning off PGO on the code responsible for it would have any noticeable change on performance. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit
OK, everyone. Both mozilla-central and mozilla-inbound are *temporarily* reopened now. Please be gentle. Cheers, -- Ehsan http://ehsanakhgari.org/ On Tue, Jan 22, 2013 at 9:06 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: Status update #3: It seems like with PGO disabled for all of the above modules, we've now decreased the linker max vmem size by about 500MB, which is nice. There is one PGO build bustage https://tbpl.mozilla.org/php/getParsedLog.php?id=19006659tree=Mozilla-Inbound which has been re-triggered, and I think we should wait to make sure that it goes green, but then we should be able to reopen mozilla-inbound temporarily, with mozilla-central following when we merge inbound to central the next time. We should get the results of the re-triggered build in about two hours. Stay tuned! Cheers, -- Ehsan http://ehsanakhgari.org/ On Mon, Jan 21, 2013 at 11:32 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: Second status update: The numbers from disabling PGO on image, accessible and webrtc are in, and the linker max vmem size is down by only ~200MB, which is quite disappointing, especially since according to Randell, putting webrtc outside of libxul should buy us something around 600MB... So, as desparate times require desparate measures, I went ahead and disabled PGO on the following components as well: rdf (the original patch there busted the tree so I backd it out), editor, svg, mathml, xslt, embedding, storage, and the old HTML parser. I will not be awake long enough tonight to see what the progress would look like, but those interested can follow along here: https://tbpl.mozilla.org/?tree=Mozilla-Inboundjobname=WINNT%205.2%20.*%20pgo-build . I'm planning to keep the tree APPROVAL REQUIRED for now. I will re-evaluate the situation tomorrow, but I do expect that we will be able to temporarily reopen the tree tomorrow. In the mean time, if you can think about more components which will not be causing a big performance problem by disabling PGO on them, please file a bug and make it block bug 832992 (and even better, copy a file like this to their top-level directory to disable PGO on them: https://hg.mozilla.org/integration/mozilla-inbound/file/357b9a855e10/rdf/defs.mk ). Thanks! -- Ehsan http://ehsanakhgari.org/ On Mon, Jan 21, 2013 at 5:36 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: Status update: we have landed three patches on mozilla-inbound which disable PGO on the following directories (rdf/, image/ and accessible/) and I have triggered PGO builds on top of them to see how much they can shave off of the linker's vmem usage. Randel is also working on taking some webrtc code out of libxul in the mean time. If all of this proves to be ineffective, we can look into de-PGO-ing more code. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit
On Wed, Jan 23, 2013 at 4:31 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: But note that unless a given code path is examined throughout the profiling phase of a PGO build, PGO will probably have negligible effect on it, if any. The PGO compiler looks for hot code paths and tries to optimize those, so for example if the awesomebar doesn't get examined during the profiling (which it isn't), it is extremely unlikely that turning off PGO on the code responsible for it would have any noticeable change on performance. I don't think this is a safe assumption. Our PGO builds not only do PGO but also Link Time Code Generation which enables cross-module optimizations. I have seen code being heavily optimized under PGO that I would not have expected to be significant in our PGO profile. It wouldn't be that hard to do an experiment to test the impact of PGO/LTCG on code that's not in the profile. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozilla-central/inbound closed -- we hit the Windows PGO memory limit
On 2013-01-22 4:40 PM, Robert O'Callahan wrote: On Wed, Jan 23, 2013 at 4:31 AM, Ehsan Akhgari ehsan.akhg...@gmail.com mailto:ehsan.akhg...@gmail.com wrote: But note that unless a given code path is examined throughout the profiling phase of a PGO build, PGO will probably have negligible effect on it, if any. The PGO compiler looks for hot code paths and tries to optimize those, so for example if the awesomebar doesn't get examined during the profiling (which it isn't), it is extremely unlikely that turning off PGO on the code responsible for it would have any noticeable change on performance. I don't think this is a safe assumption. Our PGO builds not only do PGO but also Link Time Code Generation which enables cross-module optimizations. I have seen code being heavily optimized under PGO that I would not have expected to be significant in our PGO profile. It wouldn't be that hard to do an experiment to test the impact of PGO/LTCG on code that's not in the profile. Yeah, that would probably be an interesting experiment. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Effects of JSM Compartments on Performance and Development Practices
On 1/20/13 4:01 PM, Joshua Cranmer wrote: If it were possible to have strings cross-compartments that don't require flattening and excessive copying, that would make the lives of add-on authors in a CPG world much easier. Please make sure bugs are filed? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Effects of JSM Compartments on Performance and Development Practices
On 1/20/13 2:37 PM, Gregory Szorc wrote: * Have all or most of chrome-privileged JS share the same compartment (like on B2G). It's my understanding the CPG decision was largely driven by content/security requirements and chrome just got caught up in it. What's not clear to me is whether this is a proposal to keep separate globals per JSM but have them all in one compartment or whether this is a proposal to have a single global for all JSMs, or all JSMs that opt into having this single global or something. The latter is much simpler to do. * Eliminate excessive copying and other perf issues associated with sending objects across compartments. This would be a good idea, yes. * Allow JSMs to be imported into specific named compartments. As might this be. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: IID Change Hook
On 1/22/2013 5:51 PM, Scott Johnson wrote: Hello Dev-Platform: tl;dr: As discussed in the platform meeting today, we're looking at adding a checking script to verify that IIDs are changed along with interfaces from now on. The relevant bug is https://bugzilla.mozilla.org/show_bug.cgi?id=477166 Note that we previously added a hook[1] to check that binary-compat-breaking changes on Beta didn't land without explicit approval. I suspect we could extend that hook to do what we want for mozilla-central. -Ted 1. https://bugzilla.mozilla.org/show_bug.cgi?id=813809 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Effects of JSM Compartments on Performance and Development Practices
On Tue, Jan 22, 2013 at 2:15 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/20/13 2:37 PM, Gregory Szorc wrote: * Have all or most of chrome-privileged JS share the same compartment (like on B2G). It's my understanding the CPG decision was largely driven by content/security requirements and chrome just got caught up in it. What's not clear to me is whether this is a proposal to keep separate globals per JSM but have them all in one compartment AIUI, the global-to-compartment mapping will always be 1-to-1, and changing this would be monstrously problematic. or whether this is a proposal to have a single global for all JSMs, or all JSMs that opt into having this single global or something. The compartment overhead has three components. (1) Wasted space within GC arenas (because compartments can't share arenas). This is a consistent, moderate-to-large overhead. (2) Space taken up by cross-compartment wrappers (both the objects and the CCW tables). This doesn't seem that much of a problem in practice. (3) Strings get copied between compartments. This is an irregular problem, but it can be terrible when it does occur. There are several possible fixes for this problem. https://bugzilla.mozilla.org/show_bug.cgi?id=759585 proposes introducing zones. Compartments in the same zone could share arenas, which would fix (1) (for compartments in the same zone). This would also fix (3), because compartments in the same zone would be able to share strings. https://bugzilla.mozilla.org/show_bug.cgi?id=807205 proposes a way to load multiple JS modules into the same compartment. This would also solve both (1) and (3), with the side-effect that separate modules would be sharing a global, which has some risk. https://bugzilla.mozilla.org/show_bug.cgi?id=833585 requests that strings not be copied between compartments, but if either of the previous two proposals were implemented it shouldn't be necessary. The zones approach is my preferred solution. Firefox has hundreds of compartments, and that won't change any time soon, and the separation that compartments provide gives lots of nice security/isolation benefits. Instead of finding ways to work around compartments, because they have memory overhead, it would be better to fix that memory overhead. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
B2G UA override criteria
(cross posting to dev-platform, dev-b2g, and compatibility - please respond to dev-platform) As a mitigation strategy for sites serving non mobile content to B2G, we added a UA override (domain whitelist) mechanism that allows B2G to send a custom UA to a specific domain. For example, B2G sends the Fennec UA to maps.google.com. The policy of how to add a site to the list is documented [1] but the current policy does not include the criteria that makes a site eligible for an UA override. I assert that we can't override the entire Web - at this point we should admit that the B2G UA itself needs to change. The initial approach and defacto current eligibility criteria is to limit the whitelist to the top 100 domains for target B2G locales. In support of this, UA overrides were added for sites in the top 100 Alexa ranking for specific target locales. However, there have been a number of UA override requests for domains that do not meet this criteria. I thought that it would be best to take this to the list to ensure that the discussion has a forum and that we reach a decision on the whitelist criteria. Some specific criteria to think about: 1. Should we continue to enforce a top sites threshold? If so, is 100 the right number? Is it reasonable to rely on Alexa data? 2. Should we limit the whitelist to target B2G locales? Should we accept overrides for any locale? 3. Should we limit the overall size of the whitelist? Are the technical/performance implications? Lawrence [1] https://wiki.mozilla.org/Evangelism/UA_Override_List_Policy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: IID Change Hook
Note that we previously added a hook[1] to check that binary-compat-breaking changes on Beta didn't land without explicit approval. I suspect we could extend that hook to do what we want for mozilla-central. True, but this hook actually (IIUC) checks to see if an IID changed, given a patch that's being checked in to beta without the ba= flag. The hook we'd want to implement would be quite a bit more complicated - we want to check to see if interface changes have been made without an IID change. While it's not an incredibly difficult problem, it is more complex than what bug 813809 addresses. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
