Re: Making try faster for debugging intermittents
On Fri, Jul 1, 2016 at 1:02 PM, Karl Tomlinson wrote: > William Lachance writes: > > > As part of a larger effort to improve the experience around > > debugging intermittents, I've been looking at reducing the time it > > takes for common "try" workloads for developers (so that > > e.g. retriggering a job to reproduce a failure can happen faster). > > > Also, accounts of specific try workloads of this type which are > > annoying/painful would be helpful. :) I think I have a rough idea > > of the particular type of try push I'm looking for (not pushed by > > release operations, at least one retrigger) but it would be great > > to get firsthand confirmation of that. > > One thing that might be helpful is enabling running only tests on > try with a designated build that has already been created. > > Often tests are modified to add logging, after which the same > build could be run with the new version of the test, thus saving > waiting for a build. > FWIW, there's a bug about this: https://bugzilla.mozilla.org/show_bug.cgi?id=1240644 - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Windows Defender can slow down builds and tests
Adding Firefox source directory to Windows Defender's exclusion list is the very first thing I do after I install the system. I also added the directory of MozillaBuild to the list, and the C++ compiler (cl.exe) to exclusion processes list. Not sure to what extend would that affect the build speed, though. - Xidorn On Fri, Jul 1, 2016 at 10:48 AM, Gregory Szorc wrote: > I recently started using Windows as my main development environment > (because that's what most Firefox users use and I want to improve the > Firefox development experience on Windows so more people develop on > Windows). It seems every day I find another source of painful slowdowns and > productivity issues on Windows. Today's is Windows Defender (which is > installed by default on Windows 10). > > As I measured in bug 1272851, Windows Defender slows down execution of the > xpcshell harness by ~2x. Other operations like building are also impacted. > Basically anything do lots of file creation and writes will be > significantly slower, especially on SSDs. > > Until we find a way to alert people to the negative performance impact of > Windows Defender (or most other anti-virus solutions for that matter) in > bug 1276019, I would invite you to consider having Windows Defender (or > other anti-virus products) exclude the Firefox source and object > directories so file scanning doesn't slow down I/O intensive development > operations. Of course, I can't blindly recommend you disable security. But > you should at least weigh the risks against the known productivity gains. > > Instructions for adding an exclusion to Windows Defender are available at > https://support.microsoft.com/en-us/instantanswers/64495205-6ddb-4da1-8534-1aeaf64c0af8/add-an-exclusion-to-windows-defender > . > > ___ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making try faster for debugging intermittents
William Lachance writes: > As part of a larger effort to improve the experience around > debugging intermittents, I've been looking at reducing the time it > takes for common "try" workloads for developers (so that > e.g. retriggering a job to reproduce a failure can happen faster). > Also, accounts of specific try workloads of this type which are > annoying/painful would be helpful. :) I think I have a rough idea > of the particular type of try push I'm looking for (not pushed by > release operations, at least one retrigger) but it would be great > to get firsthand confirmation of that. One thing that might be helpful is enabling running only tests on try with a designated build that has already been created. Often tests are modified to add logging, after which the same build could be run with the new version of the test, thus saving waiting for a build. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
URL translation map Re: MXR permanently offline, please transition to DXR
Gregory, Le 1 juil. 2016 à 09:33, Gregory Szorc a écrit : > I want the site to publish a "URL translation map" > for URL patterns so whole URL namespaces can be bulk updated. Interesting idea. Probably something to explain in a wiki page somewhere on https://wiki.mozilla.org/ with use cases and examples how you would see it working. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MXR permanently offline, please transition to DXR
This reminds me of a password manager bug we fixed 9 years ago (379997!), where password manager would "helpfully" delete a saved HTTP login if it got a 403 response upon using it. Unsurprisingly, this was a a terrible idea that caused your saved logins to disappear when a site was glitchy. Seem like it would be tough to find a solution to rewrite history/bookmarks that works when servers are nice, but also ignores servers that are naughty. Maybe this is addon-fodder for advanced users who want to mass-edit bookmarks and history. Justin On Thu, Jun 30, 2016 at 4:55 PM, Robert O'Callahan wrote: > In theory responses 301 and 308 mean "permanent redirect" so the browser > could do that for those responses. > > In practice you'd need a lot of data to convince yourself that Web > developers haven't screwed this up too badly. Maybe 308, being newer, is > not compromised... > > Rob > -- > lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf > toD > selthor stor edna siewaoeodm or v sstvr esBa kbvted,t > rdsme,aoreseoouoto > o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea > lurpr > .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr > esn > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for VS2013
On Tue, May 31, 2016 at 4:22 PM, Gregory Szorc wrote: > Heads up: we'll soon be dropping support for building mozilla-central with > VS2013. Bug 1186064 tracks and the patch has already received r+. > > I'm going to wait a few days before landing because this could be > disruptive and I want to at least give a heads up before I create a fire. > Please install VS2015 in the next 48 hours to avoid a surprise the next > time you pull. > The patch just landed on the autoland repo (delayed due to London and PTO). It will require VS2015u2 or newer to build (drops support for building with VS2015u1). Also, VS2015u3 was released this week. It seems to build in warnings-as-errors mode just fine locally with a vanilla mozconfig. But YMMV. Bug 1283203 getting it more officially supported. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: Windows Defender can slow down builds and tests
I recently started using Windows as my main development environment (because that's what most Firefox users use and I want to improve the Firefox development experience on Windows so more people develop on Windows). It seems every day I find another source of painful slowdowns and productivity issues on Windows. Today's is Windows Defender (which is installed by default on Windows 10). As I measured in bug 1272851, Windows Defender slows down execution of the xpcshell harness by ~2x. Other operations like building are also impacted. Basically anything do lots of file creation and writes will be significantly slower, especially on SSDs. Until we find a way to alert people to the negative performance impact of Windows Defender (or most other anti-virus solutions for that matter) in bug 1276019, I would invite you to consider having Windows Defender (or other anti-virus products) exclude the Firefox source and object directories so file scanning doesn't slow down I/O intensive development operations. Of course, I can't blindly recommend you disable security. But you should at least weigh the risks against the known productivity gains. Instructions for adding an exclusion to Windows Defender are available at https://support.microsoft.com/en-us/instantanswers/64495205-6ddb-4da1-8534-1aeaf64c0af8/add-an-exclusion-to-windows-defender . ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MXR permanently offline, please transition to DXR
On Thu, Jun 30, 2016 at 4:55 PM, Robert O'Callahan wrote: > > In theory responses 301 and 308 mean "permanent redirect" so the browser > could do that for those responses. > > In practice you'd need a lot of data to convince yourself that Web > developers haven't screwed this up too badly. Maybe 308, being newer, is > not compromised... > > To be explicit, I want a tangential feature to HTTP redirects. HTTP redirects only work on single URLs. User agents need to hit/crawl every URL and update accordingly. I want the site to publish a "URL translation map" for URL patterns so whole URL namespaces can be bulk updated. Basically exposing the URL rewrite rules from the HTTP server. Perhaps search engines already support such a feature to aid spidering? To address glandium's point, obviously this would likely only work if the old domain is still alive, as there are obvious issues with domain X trying to update URLs from domain Y! Although maybe there are tricks to establish a trusted link from old domain to new. (I'm far from an expert here.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MXR permanently offline, please transition to DXR
On Thu, Jun 30, 2016 at 04:49:26PM -0700, Gregory Szorc wrote: > On Thu, Jun 30, 2016 at 7:20 AM, Dão Gottwald wrote: > > > Can we please automatically redirect from > > https://mxr.mozilla.org/mozilla-central/source/x/y.z to > > https://dxr.mozilla.org/mozilla-central/source/x/y.z? My browsing history > > is littered with mxr URLs which used to make it very easy to find a file by > > typing part of the name. As it stands all those URLs are broken. > > > > Tangent: can we get a web feature that allows site operators to publish > "redirect rules" so user agents update references to URLs that now HTTP > 301? It makes me sad as an end user every time a domain redirects and my > awesomebar becomes less awesome because the presence of multiple domains > throws off the algorithm. And my bookmarks aren't current. And history > search yields unexpected results. And ... As a site operator, it makes me > sad that I have to keep old domains living forever. Sure, this is the point > of URLs. But sometimes I just want to pull the plug and not have to deal > with the domain registration, x509 certificates, rules in my HTTP server, > etc. How would user agents get "redirect rules" if you pull the plug on the domain registration? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MXR permanently offline, please transition to DXR
On Fri, Jul 1, 2016 at 9:55 AM, Robert O'Callahan wrote: > In theory responses 301 and 308 mean "permanent redirect" so the browser > could do that for those responses. Those would only work for as long as the 3xx is remembered, and it wouldn't work for /x if you have only seen /y redirect. To gps' question, yes, such a feature would be awesome, but it's hairy. I might be working on something that would do that, though for almost unrelated reasons. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MXR permanently offline, please transition to DXR
In theory responses 301 and 308 mean "permanent redirect" so the browser could do that for those responses. In practice you'd need a lot of data to convince yourself that Web developers haven't screwed this up too badly. Maybe 308, being newer, is not compromised... Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MXR permanently offline, please transition to DXR
On Thu, Jun 30, 2016 at 7:20 AM, Dão Gottwald wrote: > Can we please automatically redirect from > https://mxr.mozilla.org/mozilla-central/source/x/y.z to > https://dxr.mozilla.org/mozilla-central/source/x/y.z? My browsing history > is littered with mxr URLs which used to make it very easy to find a file by > typing part of the name. As it stands all those URLs are broken. > Tangent: can we get a web feature that allows site operators to publish "redirect rules" so user agents update references to URLs that now HTTP 301? It makes me sad as an end user every time a domain redirects and my awesomebar becomes less awesome because the presence of multiple domains throws off the algorithm. And my bookmarks aren't current. And history search yields unexpected results. And ... As a site operator, it makes me sad that I have to keep old domains living forever. Sure, this is the point of URLs. But sometimes I just want to pull the plug and not have to deal with the domain registration, x509 certificates, rules in my HTTP server, etc. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Adding jobs to Treeherder will now show a 'Sch' job with the outcome of the request
Hello all, Until now, adding jobs to Treeherder was completely opaque. As of today you will see a "Sch" job start running soon after you make your request. You will have access to logs and a link to file a bugs. Filing bugs will help when my alerting system does not catch issues. I have all information and screenshots in here: https://armenzg.blogspot.ca/2016/06/adding-new-jobs-to-treeherder-is-now.html Please let me know if you find any bugs. Happy hacking, Armen -- Zambrano Gasparnian, Armen Automation & Tools Engineer http://armenzg.blogspot.ca ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MXR permanently offline, please transition to DXR
Hi, Kendall. As a pain mitigation strategy for MXR URLs embedded immutably in Bugzilla and in people's Awesomebar histories, can we redirect MXR requests as Dão suggests? Some won't work, but many will, and those people will be less sad. > On Jun 30, 2016, at 10:20 , Dão Gottwald wrote: > > Can we please automatically redirect from > https://mxr.mozilla.org/mozilla-central/source/x/y.z to > https://dxr.mozilla.org/mozilla-central/source/x/y.z? My browsing history > is littered with mxr URLs which used to make it very easy to find a file by > typing part of the name. As it stands all those URLs are broken. > > 2016-06-22 20:30 GMT+02:00 Lawrence Mandel : > >> Mozilla Cross-Reference, better known as MXR (https://mxr.mozilla.org), >> was taken offline on June 13, 2016, to investigate a potential security >> issue. After careful review of the codebase, we have decided to accelerate >> the planned transition from MXR to its more modern equivalent, DXR ( >> https://dxr.mozilla.org), instead of bringing MXR back online. As far as >> we know there was never a security compromise, but the unsupported legacy >> codebase (forked from an old version of LXR) would require significant time >> and effort to rewrite and bring up to spec. >> >> Our transition plan is as follows: >> >> >> - >> >> Add an interstitial web page at https://mxr.mozilla.org that displays >> a best-guess URL for the equivalent https://dxr.mozilla.org file data. >> This will help interactive users retrieve data from historical links in >> applications like Bugzilla. >> - >> >> Redirect certdata.txt and effective_tld_names.dat to their canonical >> source code repositories instead of DXR. All other search queries and >> automatic pulling of raw files by third parties will no longer be supported >> at the https://mxr.mozilla.org URL. >> - >> >> Index the remaining repos listed in MXR in DXR for data parity, using >> bug 1281443 to track progress. Repos will be indexed in the order listed >> unless otherwise specified. If you need to prioritize the indexing of >> specific repos, please open a bug and block against bug 1281443. >> >> >> Our expectation is that the interstitial page will be in place and the >> following remaining high-priority repos will be indexed by June 24th, 2016: >> >> - >> >> add-ons >> - >> >> servo >> - >> >> l10n >> >> >> If you have concerns, questions, or requests, please open a new bug and >> mark it as blocking bug 1281443 or add a comment to one of its existing >> dependent bugs. Additional status updates will also be posted to bug >> 1281443 and its dependent bugs. >> >> Lawrence >> >> ___ >> firefox-dev mailing list >> firefox-...@mozilla.org >> https://mail.mozilla.org/listinfo/firefox-dev >> >> > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Making try faster for debugging intermittents
As part of a larger effort to improve the experience around debugging intermittents, I've been looking at reducing the time it takes for common "try" workloads for developers (so that e.g. retriggering a job to reproduce a failure can happen faster). Of course, the common advice of "profile before you optimize" applies here. That is to say, we want to spend time optimizing what makes this particular task painful, rather than optimizing try in general. To start with, I've been using a manually generated dump of the jobs posted to try on treeherder in a 10 day span. You can see some preliminary results of me manipulating the data to get some rough information (last job for each try push, and total machine time for each job) here: http://nbviewer.jupyter.org/url/people.mozilla.org/%7Ewlachance/try%20analysis.ipynb Before I go much further, I'd love to know if anyone has done similar explorations in the recent past and if there are any aggregation points other than Treeherder (taskcluster? buildbot?) which are storing this information: my working assumption is that treeherder is the best place to analyze this information (since it acts as a central point of aggregation), but I'm open to being proven wrong. Also, accounts of specific try workloads of this type which are annoying/painful would be helpful. :) I think I have a rough idea of the particular type of try push I'm looking for (not pushed by release operations, at least one retrigger) but it would be great to get firsthand confirmation of that. Will ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko shutdown (London session)
Hi Aaron, others, On Thu, Jun 30, 2016 at 8:41 AM, Aaron Klotz wrote: > Did the now-defunct exit(0) project ever come up in this discussion? > > See bugs 662444 and 826143. This was a perf team project back in the > Snappy days where the objective was to write important data to disk ASAP, > then exit(0) without doing a bunch of cleanup. The argument for this was > that, yes, during development we want to make sure that we are properly > cleaning up after ourselves, but there is no reason for end users with opt > builds to be waiting around while Firefox spends a bunch of time destroying > things that are going to be wiped anyway by process termination. > I'd like to (re-)surface that exit(0) is never going to be feasible on Android [1]. The Android process hosts many long-lived services with lifecycles distinct from the lifecycle of the Gecko rendering engine. In some way, Fennec needs to be able to "shutdown" Gecko without Gecko killing its process. (For the record: separating Gecko into its own process is technically feasible but I expect it to be a great deal of work that I definitely think we should not do. JNI across processes is probably possible but definitely not pleasant!) Nick [1] If necessary, I can dig out Bugzilla links to discussions that have taken place about this. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko shutdown (London session)
On 06/30/2016 11:49 AM, Nicolas Silva wrote: Hi dev-platform, We had a session about shutdown problems during the London workweek. I did a writeup of what was discussed and as it grew into a large-ish piece, I put it in a wiki page (instead of the email I intended to send initially) [1]. There's been a lot of work on reducing shutdown crashes/hangs (especially with e10s) this year, but we still have a lot of work to do [2]. The page contains some discussions about the kinds of issues we ran into in the gfx team and of how we went about addressing some of them. If you are working on shutdown problems, you may (or may not) find useful information in there. If you have some experience with dealing with shutdown bugs, I encourage you to do a brain dump on that wiki page. There's also a two-phase shutdown proposal briefly described in there [3], that is worth discussing because it would involve some cooperation between different modules. "Phase 1: All modules destroy all of their dynamic objects, but stay in a usable state. No more DOM objects or documents or gpu textures floating around at the end of this phase. If the cycle collector is still retaining resources at this point, it's a bug. " Not sure if this matters here, but cycle collector doesn't really retain objects. Sure, we could explicitly clear so called jsholders, so that C++->JS edges are manually cut. But in general, CC doesn't know about a cycle collectable objects unless the object has been addrefed/released after the previous cycle collection. (those operations make the object suspected, so the object is put to cycle collector's purple buffer). Note, we do have shutdown leaks occasionally dealing with cycle collectable objects. It may be because of some JS using random services in a bad way or someone forgetting to traverse/unlink some cycle collabtable member variable, or non-cycle collectable object keeping a strong reference to a cycle collectable object etc. Shutdown leaks are always considered bugs, so nothing new there, but they do happen and other code needs to be aware of it and not crash in a bad way if that happens. Cheers, Nical [1] https://wiki.mozilla.org/Gecko:Shutdown_issues [2] https://crash-stats.mozilla.com/search/?product=Firefox&shutdown_progress=shutdown&_facets=signature&_columns=date&_columns=signature&_columns=version&_columns=build_id&_columns=platform&_columns=shutdown_progress#facet-signature [3] https://wiki.mozilla.org/Gecko:Shutdown_issues#Two-phase_shutdown_proposal ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MXR permanently offline, please transition to DXR
Can we please automatically redirect from https://mxr.mozilla.org/mozilla-central/source/x/y.z to https://dxr.mozilla.org/mozilla-central/source/x/y.z? My browsing history is littered with mxr URLs which used to make it very easy to find a file by typing part of the name. As it stands all those URLs are broken. 2016-06-22 20:30 GMT+02:00 Lawrence Mandel : > Mozilla Cross-Reference, better known as MXR (https://mxr.mozilla.org), > was taken offline on June 13, 2016, to investigate a potential security > issue. After careful review of the codebase, we have decided to accelerate > the planned transition from MXR to its more modern equivalent, DXR ( > https://dxr.mozilla.org), instead of bringing MXR back online. As far as > we know there was never a security compromise, but the unsupported legacy > codebase (forked from an old version of LXR) would require significant time > and effort to rewrite and bring up to spec. > > Our transition plan is as follows: > > >- > >Add an interstitial web page at https://mxr.mozilla.org that displays >a best-guess URL for the equivalent https://dxr.mozilla.org file data. >This will help interactive users retrieve data from historical links in >applications like Bugzilla. >- > >Redirect certdata.txt and effective_tld_names.dat to their canonical >source code repositories instead of DXR. All other search queries and >automatic pulling of raw files by third parties will no longer be supported >at the https://mxr.mozilla.org URL. >- > >Index the remaining repos listed in MXR in DXR for data parity, using >bug 1281443 to track progress. Repos will be indexed in the order listed >unless otherwise specified. If you need to prioritize the indexing of >specific repos, please open a bug and block against bug 1281443. > > > Our expectation is that the interstitial page will be in place and the > following remaining high-priority repos will be indexed by June 24th, 2016: > >- > >add-ons >- > >servo >- > >l10n > > > If you have concerns, questions, or requests, please open a new bug and > mark it as blocking bug 1281443 or add a comment to one of its existing > dependent bugs. Additional status updates will also be posted to bug > 1281443 and its dependent bugs. > > Lawrence > > ___ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MXR permanently offline, please transition to DXR
On 06/28/16 01:01, Tanvi Vyas wrote: Is it possible to safely redirect mxr to dxr? This would be most welcome. There are lots of pasted MXR links in Bugzilla comments which now requires tedious editing to follow. /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko shutdown (London session)
On Thu, Jun 30, 2016 at 8:41 AM, Aaron Klotz wrote: > Did the now-defunct exit(0) project ever come up in this discussion? > > See bugs 662444 and 826143. This was a perf team project back in the > Snappy days where the objective was to write important data to disk ASAP, > then exit(0) without doing a bunch of cleanup. The argument for this was > that, yes, during development we want to make sure that we are properly > cleaning up after ourselves, but there is no reason for end users with opt > builds to be waiting around while Firefox spends a bunch of time destroying > things that are going to be wiped anyway by process termination. > We already do _exit(0) in content processes in non-debug e10s, in ContentChild::ActorDestroy(). A lot of the mess that Nicolas has had to deal with in shutdown is in debug builds (see bug 1215265 and friends), so exit(0) won't help with that. > > Aaron > > > On 6/30/2016 2:49 AM, Nicolas Silva wrote: > >> Hi dev-platform, >> >> We had a session about shutdown problems during the London workweek. I >> did a writeup of what was discussed and as it grew into a large-ish >> piece, I put it in a wiki page (instead of the email I intended to send >> initially) [1]. >> There's been a lot of work on reducing shutdown crashes/hangs >> (especially with e10s) this year, but we still have a lot of work to do >> [2]. >> >> The page contains some discussions about the kinds of issues we ran into >> in the gfx team and of how we went about addressing some of them. If you >> are working on shutdown problems, you may (or may not) find useful >> information in there. If you have some experience with dealing with >> shutdown bugs, I encourage you to do a brain dump on that wiki page. >> >> There's also a two-phase shutdown proposal briefly described in there >> [3], that is worth discussing because it would involve some cooperation >> between different modules. >> >> Cheers, >> >> Nical >> >> [1] https://wiki.mozilla.org/Gecko:Shutdown_issues >> [2] >> >> https://crash-stats.mozilla.com/search/?product=Firefox&shutdown_progress=shutdown&_facets=signature&_columns=date&_columns=signature&_columns=version&_columns=build_id&_columns=platform&_columns=shutdown_progress#facet-signature >> [3] >> https://wiki.mozilla.org/Gecko:Shutdown_issues#Two-phase_shutdown_proposal >> >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko shutdown (London session)
Cool, thanks for the refresh on those details. Clearly this still involves a bunch of work, but so would any other shutdown improvement project. My concern is that if we are going to reexamine shutdown, then I think that exit(0) needs to fit into this somehow. If we're going to spend the resources to refactor a bunch of stuff in the shutdown sequence, we're not maximizing the benefit to the user without it. On 6/30/2016 9:44 AM, David Rajchenbach-Teller wrote: There were plenty of blockers for _exit(0), including the fact that pretty much none of the async code in Firefox/Gecko was shutdown-safe. That's one of the reasons we had to come up with nsIAsyncShutdown/AsyncShutdown.jsm. One of the not-entirely-stated goals was that once everything registered with AsyncShutdown had finished shutting down, we could call _exit(0). Cheers, David On 30/06/16 17:41, Aaron Klotz wrote: Did the now-defunct exit(0) project ever come up in this discussion? See bugs 662444 and 826143. This was a perf team project back in the Snappy days where the objective was to write important data to disk ASAP, then exit(0) without doing a bunch of cleanup. The argument for this was that, yes, during development we want to make sure that we are properly cleaning up after ourselves, but there is no reason for end users with opt builds to be waiting around while Firefox spends a bunch of time destroying things that are going to be wiped anyway by process termination. Aaron ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko shutdown (London session)
There were plenty of blockers for _exit(0), including the fact that pretty much none of the async code in Firefox/Gecko was shutdown-safe. That's one of the reasons we had to come up with nsIAsyncShutdown/AsyncShutdown.jsm. One of the not-entirely-stated goals was that once everything registered with AsyncShutdown had finished shutting down, we could call _exit(0). Cheers, David On 30/06/16 17:41, Aaron Klotz wrote: > Did the now-defunct exit(0) project ever come up in this discussion? > > See bugs 662444 and 826143. This was a perf team project back in the > Snappy days where the objective was to write important data to disk > ASAP, then exit(0) without doing a bunch of cleanup. The argument for > this was that, yes, during development we want to make sure that we are > properly cleaning up after ourselves, but there is no reason for end > users with opt builds to be waiting around while Firefox spends a bunch > of time destroying things that are going to be wiped anyway by process > termination. > > Aaron > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko shutdown (London session)
Did the now-defunct exit(0) project ever come up in this discussion? See bugs 662444 and 826143. This was a perf team project back in the Snappy days where the objective was to write important data to disk ASAP, then exit(0) without doing a bunch of cleanup. The argument for this was that, yes, during development we want to make sure that we are properly cleaning up after ourselves, but there is no reason for end users with opt builds to be waiting around while Firefox spends a bunch of time destroying things that are going to be wiped anyway by process termination. Aaron On 6/30/2016 2:49 AM, Nicolas Silva wrote: Hi dev-platform, We had a session about shutdown problems during the London workweek. I did a writeup of what was discussed and as it grew into a large-ish piece, I put it in a wiki page (instead of the email I intended to send initially) [1]. There's been a lot of work on reducing shutdown crashes/hangs (especially with e10s) this year, but we still have a lot of work to do [2]. The page contains some discussions about the kinds of issues we ran into in the gfx team and of how we went about addressing some of them. If you are working on shutdown problems, you may (or may not) find useful information in there. If you have some experience with dealing with shutdown bugs, I encourage you to do a brain dump on that wiki page. There's also a two-phase shutdown proposal briefly described in there [3], that is worth discussing because it would involve some cooperation between different modules. Cheers, Nical [1] https://wiki.mozilla.org/Gecko:Shutdown_issues [2] https://crash-stats.mozilla.com/search/?product=Firefox&shutdown_progress=shutdown&_facets=signature&_columns=date&_columns=signature&_columns=version&_columns=build_id&_columns=platform&_columns=shutdown_progress#facet-signature [3] https://wiki.mozilla.org/Gecko:Shutdown_issues#Two-phase_shutdown_proposal ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko shutdown (London session)
On Thu, Jun 30, 2016, at 04:35 PM, smaug wrote: > Not sure if this matters here, but cycle collector doesn't really retain > objects. Sure, we could explicitly clear so called jsholders, so that > C++->JS > edges are manually cut. But in general, CC doesn't know about a cycle > collectable objects unless the object has been addrefed/released after > the > previous cycle collection. > (those operations make the object suspected, so the object is put to > cycle collector's purple buffer). Yeah, sorry, the wording was inaccurate. Something phrased like this would make more sense: All modules should deallocate all or as much as they can of their short-lived objects during phase 1 so that at the end of phase 1 a cycle collection is run and all cycles are already broken. If a cycle still exist at this point, it should be considered a bug. The problems we currently are not the CC's "fault", it comes from garbage collected and reference-counted objects being destroyed at various times during ShutdownXPCOM, which means we have to shut the CC down (and run the last cycle-collection which will free some more dynamic objects) at the very end when there isn't much left of gecko that is in a valid state. I'll clarify in the document. Cheers, Nical ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: enabling auto-shutdown and restart of osfile async worker on nightly
This is live in today's nightly. Again, please let me know if you run into problems. Thanks! Ben On Tue, Jun 28, 2016 at 3:01 PM, Ben Kelly wrote: > Hi all, > > Please be aware I'm going to try enabling this pref on nightly later today: > > osfile.reset_worker_delay > > This will allow us to clean up the osfile async worker when its not in use > to save system resources. It will then automatically restart the worker > the next time its needed. > > This is only being enabled on non-release builds right now until we can > show that it doesn't cause any regressions. Talos and try are green, but > its possible there are unknown race condition bugs. > > See this bug: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1279389 > > If you have any issues with the osfile async methods on nightly/aurora, > please try disabling the pref above. Also please let me know so that I can > investigate why it broke. > > Thanks. > > Ben > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship: WindowClient.navigate()
Summary: Load a specified URL in a controlled client page. Part of the service workers spec Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1218148 Link to standard: https://www.w3.org/TR/service-workers/#client-navigate-method Platform coverage: All platforms Estimated or target release: Firefox 51 Preference behind which this will be implemented: None DevTools bug: None. Is there a need for one? Do other browser engines implement this? Chrome 49.0 farre ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Gecko shutdown (London session)
Hi dev-platform, We had a session about shutdown problems during the London workweek. I did a writeup of what was discussed and as it grew into a large-ish piece, I put it in a wiki page (instead of the email I intended to send initially) [1]. There's been a lot of work on reducing shutdown crashes/hangs (especially with e10s) this year, but we still have a lot of work to do [2]. The page contains some discussions about the kinds of issues we ran into in the gfx team and of how we went about addressing some of them. If you are working on shutdown problems, you may (or may not) find useful information in there. If you have some experience with dealing with shutdown bugs, I encourage you to do a brain dump on that wiki page. There's also a two-phase shutdown proposal briefly described in there [3], that is worth discussing because it would involve some cooperation between different modules. Cheers, Nical [1] https://wiki.mozilla.org/Gecko:Shutdown_issues [2] https://crash-stats.mozilla.com/search/?product=Firefox&shutdown_progress=shutdown&_facets=signature&_columns=date&_columns=signature&_columns=version&_columns=build_id&_columns=platform&_columns=shutdown_progress#facet-signature [3] https://wiki.mozilla.org/Gecko:Shutdown_issues#Two-phase_shutdown_proposal ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
