Tabs hang with 100% CPU in e10s

Girish Sharma 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:
>
> https://addons.mozilla.org/en-US/firefox/addon/add-on-
> compatibility-reporter/
>
> 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
> anything
> >     else".
> >
> >     With content split out into its own process, we have the main process
> >     and content process acting somewhat independently of one another.
> They
> >     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
> our
> >     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
> to
> >     stop what it's doing, because we need the answer synchronously
> ("right
> >     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
> user
> >     events when it's blocked.
> >
> >     Built-in Firefox code has been re-engineered over the past few years
> to
> >     not access web content synchronously anymore - but older add-ons
> still
> >     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
> work
> >     both ways).
> >
> >     What this means is that an add-on using the shim layer can work
> without
> >     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
> you
> >     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
>



-- 
Girish Sharma
B.Tech(H), Civil Engineering,
Indian Institute of Technology, Kharagpur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161208/8405a90f/attachment.html>


More information about the firefox-dev mailing list