Tabs hang with 100% CPU in e10s
scrapmachines at gmail.com
Thu Dec 8 10:21:02 UTC 2016
I have been selectively disabling addons and trying out for a couple of
days. Then I finally came to no addons and have been running my Nightly
without any addons since yesterday now. The issue still persists, thus I
feel that this is not any of the addons' issue.
On Fri, Nov 25, 2016 at 9:26 PM, Mike Conley <mconley at mozilla.com> wrote:
> I believe the Add-on Compatibility Reporter will show multi-process
> compatibility in about:addons after installed and enabled:
> On 25/11/2016 10:51 AM, Girish Sharma wrote:
> > Thanks for the detailed info! I myself have authored some addons, so I
> > know about addon code and debugging them. How do I check if the addon
> > has explicitly opted out to use this shim or not?
> > Regards
> > On Fri, Nov 25, 2016 at 9:16 PM, Mike Conley <mconley at mozilla.com
> > <mailto:mconley at mozilla.com>> wrote:
> > Sorry - didn't mean to sling jargon at you. Happy to clear this up:
> > Add-ons have traditionally had no problems directly accessing web
> > content "synchronously", which means "right away before doing
> > else".
> > With content split out into its own process, we have the main process
> > and content process acting somewhat independently of one another.
> > run their own event loops, they do their own garbage and cycle
> > collection, etc.
> > This means that in order to access web content "synchronously" in the
> > multi-process model, we have to tell the content process to stop
> > whatever it's doing (which can sometimes take some time), respond to
> > command, and return a result. There's some complexity there that I'm
> > glossing over, but that's essentially the model.
> > The problem with that is while we're waiting for the content process
> > stop what it's doing, because we need the answer synchronously
> > away before doing anything else"), that means that the main thread in
> > the parent process is blocked waiting for the reply from the content
> > process. That makes it unresponsive, because it cannot respond to
> > events when it's blocked.
> > Built-in Firefox code has been re-engineered over the past few years
> > not access web content synchronously anymore - but older add-ons
> > sometimes use the old model. Instead of breaking those add-ons, we
> > created this "shim" layer, which transparently send those synchronous
> > messages to the content process (or to the parent process - it can
> > both ways).
> > What this means is that an add-on using the shim layer can work
> > changing any of it's code, at the cost of performance and
> > responsiveness, because it's doing the Bad Thing: sending synchronous
> > messages to the content process.
> > Add-ons automatically use the shim layer unless they opt out, so if
> > have some add-ons in your profile that haven't opted out, they'll be
> > using them - and if they attempt to touch web content a lot (older
> > versions of LastPass, for example, did this), this will really bring
> > browser performance down due to the synchronous messaging.
> > Anyhow, I hope that answered your question.
> > -Mike
> > On 25/11/2016 10:32 AM, Girish Sharma wrote:
> > >
> > > On Fri, Nov 25, 2016 at 8:57 PM, Mike Conley <mconley at mozilla.com
> <mailto:mconley at mozilla.com>
> > > <mailto:mconley at mozilla.com <mailto:mconley at mozilla.com>>> wrote:
> > >
> > > shimmed add-on
> > >
> > >
> > > What is a shimmed add-on?
> > >
> > >
> > > --
> > > Girish Sharma
> > > B.Tech(H), Civil Engineering,
> > > Indian Institute of Technology, Kharagpur
> > --
> > Girish Sharma
> > B.Tech(H), Civil Engineering,
> > Indian Institute of Technology, Kharagpur
B.Tech(H), Civil Engineering,
Indian Institute of Technology, Kharagpur
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the firefox-dev