BaseThreadInitThunk potential collateral benefits
Hi. I wanted to call attention to https://bugzilla.mozilla.org/show_bug.cgi?id=1322554 (Startup crashes in BaseThreadInitThunk since 2016-12-03) -- a startup crash resulting from DLL injection early in the process -- which was resolved fixed for 32bit Windows on 5/24. This particular fix[0] has the potential side effect of solving other bugs as well, ones that may have very different signatures that deal with remotely-injected code[1]. Just a caution that it's not going to impact all injection issues. We know that there is an as-yet-unidentified increase and decrease in this crash prior to patch landing[2]. Carl Corcoran, who landed this, will be looking at that time period as well to attempt to find contributing causes (any help diagnosing is probably welcome, though I defer to ccorcoran). Also, just a shout out that this was Carl's first patch. Thanks! [0] The proposed/chosen solution is roughly here: https://bugzilla.mozilla.org/show_bug.cgi?id=1322554#c69 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1322554#c168 [2] https://crash-stats.mozilla.com/signature/?product=Firefox&release_channel=release&signature=BaseThreadInitThunk&date=%3E%3D2016-12-05T14%3A42%3A31.000Z&date=%3C2017-06-05T14%3A42%3A31.000Z#graphs -- David Durst [:ddurst] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Quantum Flow Engineering Newsletter #18
While we're pushing forward on Quantum Flow things, there are a lot of people looking to help out where they can. To make this at least a little organized, please remember to assign a bug to yourself if you're working on it (or planning to). https://charts.mozilla.org/quantum/blockers.html# is showing a few unassigned that are actually assigned (judging from the comments). Similarly, if something IS assigned to you, but it's not actively being worked on and you're OK with someone else doing so, please un-assign yourself. Thanks... -- David Durst [:ddurst] On Tue, Aug 8, 2017 at 9:26 AM, Mike Conley wrote: > Mike Conley ported scrollbox to use smooth scrolling instead of JS driven >> scrolling <https://bugzilla.mozilla.org/show_bug.cgi?id=1356705>. This >> affects most importantly scrolling the tab bar, and should make it more >> smooth by removing a lot of slow code that used to run and off-loading that >> work to the compositor through CSS-based smooth scrolling! He notes >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1356705#c67> on the bug >> that in order to achieve great performance some follow-ups may be needed. > > > Just to ensure credit is given where it's due - that was 95% Dão > Gottwald's work. I just helped push the last 5% over the line when he got > focused on getting square tabs landed. Thanks Dão! > > On 4 August 2017 at 04:04, Ehsan Akhgari wrote: > >> Hi everyone, >> >> This has been a busy week. A lot of fixes have landed, setting up the >> Firefox 57 cycle for a good start. On the platform side, a notable change >> that will be in the upcoming Nightly is the fix for document.cookie using >> synchronous IPC. This super popular API call slows down various web pages >> today in Firefox, and starting from tomorrow, the affected pages should >> experience a great speedup. I have sometimes seen the slowdown caused by >> this one issue to amount to a second or more in some situations, thanks a >> lot to Amy and Josh for their hard work on this feature. The readers of >> these newsletters know that the work on fixing this issue has gone on for a >> long time, and it's great to see it land early in the cycle. >> >> On the front-end side, more and more of the UI changes of Photon are >> landing in Nightly. One of the overall changes that I have seen is that >> the interface is starting to feel a lot more responsive and snappy than it >> was around this time last year. This is due to many different details. A >> lot of work has gone into fixing rough edges in the performance of the >> existing code, some of which I have covered but most of which is under the >> Photon >> Performance project >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1363750>. Also the new UI >> is built with performance in mind, so for example where animations are >> used, they use the compositor and don't run on the main thread. All of the >> pieces of this performance puzzle are nicely coming to fit in together, and >> it is great to see that this hard work is paying off. >> >> On the Speedometer front, things are progressing with fast pace. We have >> been fixing issues that have been on our list from the previous findings, >> which has somewhat slowed down the pace of finding new issues to work on. >> Although the SpiderMonkey team haven't waited around >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1245279> and are >> continually finding new optimization opportunities out of further >> investigations. There is still more work to be done there! >> >> I will now move own to acknowledge the great work of all of those who >> helped make Firefox faster last week. I hope I am not mistakenly >> forgetting any names here! >> >>- Andrew McCreight got rid of some cycle collector overhead >><https://bugzilla.mozilla.org/show_bug.cgi?id=1385459> related to >>using QueryInterface to canonicalize the nsISupports pointers stored in >> the >>purple buffer, and similarly for pointers encountered during >>traversal of native roots >><https://bugzilla.mozilla.org/show_bug.cgi?id=1385474> as well. >>- Kris Maglione added some utilities to BrowserUtils >><https://bugzilla.mozilla.org/show_bug.cgi?id=1383367> that should >>help our front-end devs avoid synchronous layout and style flushes. >>- Amy Chung got rid of the sync IPC messages in the cookie service >><https://bugzilla.mozilla.org/show_bug.cgi?id=1331680>! This was a >>substantial amount of work and should eliminate jank on a number of
Re: Website memory leaks
What you're describing having seen is, I think, exactly what I've been trying to reproduce in a now-blocking-57 bug (1398652). By your description, the only thing that makes sense to me -- to account for unknown/unknowable changes on the site -- is to track potential runaway growth of the content process. I realize how stupid this sounds, but what I observed was that when the content process was in trouble, it continued to grow. And the effect/impact builds: first the tab, then the process, then the browser, then the OS. So if there's a way to determine that "this process has only grown in the past X amount of time" or past a certain threshold, that's the best indicator I've come up with. I don't know what we'd do at that point -- force killing the content process sounds severe (though possibly correct) -- or some alert similar to the dreaded slow script one. -- David Durst [:ddurst] On Thu, Nov 2, 2017 at 11:31 AM, Randell Jesup wrote: > >about:performance can provide the tab/pid mapping, with some performance > >indexes. > >This might help solve your issue listed in the side note. > > mconley told me in IRC that today's nightly has brought back the PID in > the tooltip (in Nightly only); it was accidentally removed. > > about:performance can be useful, but 3 tabs vs all tabs is too coarse > for me, and things like "site leaked memory and is slowing CC" I presume > doesn't show up in the 'heat' for the tab there. > > -- > Randell Jesup, Mozilla Corp > remove "news" for personal email > ___ > 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: CPU core count game!
Just noting that there's bug 1399962 right now -- and if you're single core (like a large portion of very affordable PCs in the past two years or so), the problem can be so bad (bug 1431835) that common sites like amazon can turn Firefox into a not viable option. -- David Durst [:ddurst] On Tue, Mar 27, 2018 at 5:02 PM, Mike Conley wrote: > Thanks for drawing attention to this, sfink. > > This is likely to become more important as we continue to scale up our > parallelization with content processes and threads. > > On 21 March 2018 at 14:54, Steve Fink wrote: > > > Just to drive home a point, let's play a game. > > > > First, guesstimate what percentage of our users have systems with 2 or > > fewer cores. > > > > Then visit https://hardware.metrics.mozilla.com/#goto-cpu-and-memory to > > check your guess. > > > > (I didn't say it was a *fun* game.) > > > > > > ___ > > 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
