e10s support question

[ownedbywuigi]

I was wondering why both Pale Moon and other UXP browsers do not support e10s *at all*, wherever that be via a preference or enabled by defualt.

If it is on purpose, can we at least have it behind a preference (either in about:config or the browser's settings panel) for the user's convenience and the fixing of the browser "freezing"

[jobbautista9]

See this forum post: Multi-process, or: the drawbacks nobody ever talks about.

There is no plan whatsoever to support this, not even behind a disabled-by-default pref.

Btw if you're serious about supporting e10s in your fork you should probably look at the hundreds of security advisories by Mozilla related to multi-process and backport their fixes. Otherwise you're just opening yourself to the hundreds of vulnerabilities already fixed by upstream that have been considered N/A for us (due to sticking with the single-process model) for a long time.

[ownedbywuigi]

Btw if you're serious about supporting e10s in your fork you should probably look at the hundreds of security advisories by Mozilla related to multi-process and backport their fixes. Otherwise you're just opening yourself to the hundreds of vulnerabilities already fixed by upstream that have been considered N/A for us (due to sticking with the single-process model) for a long time.

Working on backporting their fixes as we speak

[jobbautista9]

Off-topic:
You might find this list useful too: https://github.com/BrowserWorks/Waterfo ... Advisories

There are bugs related to WebExtensions which you intend to support as well.

[ownedbywuigi]

Off-topic:
You might find this list useful too: https://github.com/BrowserWorks/Waterfo ... Advisories

There are bugs related to WebExtensions which you intend to support as well.

Off-topic:
Will get those fixed up too.

[athenian200]

I was wondering why both Pale Moon and other UXP browsers do not support e10s *at all*, wherever that be via a preference or enabled by defualt.

If it is on purpose, can we at least have it behind a preference (either in about:config or the browser's settings panel) for the user's convenience and the fixing of the browser "freezing"

To my knowledge, it's partly because e10s makes XUL extensions not work very well when you have multiple tabs open... they were designed around single-process browsers, and the issues with e10s were part of why Firefox ditched them for WebComponents. Job mentioned security issues, but I don't think that's the primary reason, more of a side benefit. The other issue is I believe at least some of the code they used to go e10s was implemented in Rust, which we don't want. Probably not so much of it that a half-baked e10s with a lot of issues couldn't be done, but enough that it was seen as a bad idea for our goals as a project.

I get why someone would want to try implementing e10s, though. It would help take advantage of multi-core processors more easily. Though I will say, if I wanted to do it, I would not do it the way Mozilla did it. Instead, I'd probably attempt to do it in a way that preserved XUL compatibility a bit better. Like for instance, having a root window process that uses the user's browser theme, along with any extensions that purely impact the GUI and avoid touching web content. Essentially, it would purely have the browser chrome and nothing else. Something that just sits on the desktop without having any tabs open, sort of a multi-document interface ready to go that won't parse any web content itself. Then having each tab be a new full instance of the browser, without a titlebar or controls, drawn inside a tab, with only extensions that touch web content running inside it, primarily the JavaScript parts that can manipulate web content. Essentially the trickiest part of this would be having to enforce a hard split between XUL chrome extensions that touch the browser interface, and XUL content extensions that are basically just hooks into the JS engine of a content process that modify what the user sees... and setting it up so the chrome extensions can control the content extensions in a secure manner. It's not easy, and I think that's why Mozilla gave up and killed XUL as part of their e10s migration, especially with WebComponents already existing and being popular they didn't see a need to put in the engineering work to make a multiprocess-resilient architecture for XUL. I'm sure they could have, but they didn't.

To get a preview of what this model might feel like if it could be made to work, but in a slightly inconvenient way... just launch multiple instances of your preferred UXP browser under different profiles, don't use tabbed browsing, and switch between them using the Windows Taskbar as your "tab manager" instead. You'll notice things work a lot faster, while still having XUL. That's why I think a split like that could potentially work to preserve XUL while having multiprocess, but system requirements would skyrocket, IPC would have to be handled carefully to coordinate communication between the "chrome side" and the "content side" of an XUL extension, and you would absolutely need each page to be running in a full browser process, not an e10s thing where all the different components of the browser are their own process.

But seriously, if you do want e10s as Mozilla did it to see if you think you can get XUL to work well with it, it might be easier to fork a newer version of Firefox and try to add XUL back in than to work from UXP or one of its forks... a lot of that stuff was explicitly ripped out, and wasn't really complete when we forked off anyway. At least that's my impression?

[ownedbywuigi]

But seriously, if you do want e10s as Mozilla did it to see if you think you can get XUL to work well with it, it might be easier to fork a newer version of Firefox and try to add XUL back in than to work from UXP or one of its forks... a lot of that stuff was explicitly ripped out, and wasn't really complete when we forked off anyway. At least that's my impression?

I fixed some bugs in Serpent (Basilisk)'s handling of e10s such as a input recession (how??????) but I'll try to make it more feature and bug complete with what roytam1's basilisk55 and/or Mypal68's e10s is like.

[Moonchild]

While we still have some vestiges of e10s, it should not be considered usable or anywhere near complete.
As pointed out as well there are hundreds of sec issues in e10s we never adressed for being out of scope for our development. If you enable it by force you are destroying the security of your browser.

Working on backporting their fixes as we speak

I'm pretty certain you don't know of or have access to many of the sec bugs caused directly or indirectly by e10s. I really don't think you want to do this on UXP. Your fork of course, so you can decide for yourself, but be very aware of what you are getting yourself into if you continue building on our platform for e10s use.

If it wasnt for oop plugin usage, we likely would have removed all IPC code from the platform already but as it is we still wanted it for that use... But that does not make it safe for web content and js.

[ownedbywuigi]

I really don't think you want to do this on UXP. Your fork of course, so you can decide for yourself, but be very aware of what you are getting yourself into if you continue building on our platform for e10s use.

I will make it still an OPTION, but be disabled by default and have a disclaimer when the user tries to turn it on (in a later commit but before 13.1 release).

I can see that it is still very much unstable though, and will adknowledge your disclaimer.

[Mæstro]

I would like to mention another point against many-process software like Electrolysis which I see neglected. A single process is less resource-intensive, which can be quite important, among other places, on older computers. I appreciate that Pale Moon will always be confined to just one of my computer’s four processors. It keeps the average processor temperature down, and guarantees that a bad site cannot lock up my whole computer this way. Keeping older computers in use and using fewer system resources (which correspond directly to energy) are both virtues. Thrift and simplicity are virtues.

[UCyborg]

It's not technically confined to one core even now as it is, being multi-threaded application. Some captchas get it to put good load on multiple cores.

Single thread can also be migrated between CPUs. If you want to actually confine it to one core, then you would have to set process affinity accordingly.

But, considering current code base is a mess as-it-is (IMHO) and workability and reliability of classic extensions under e10s is under question... Firefox seemed fine back in the day, then they kept piling shit on top and it kept getting slower and buggier. Considering issues encountered throughout my years of using Pale Moon, it still has that sting of its Firefox heritage to it.

But Firefox today isn't better, recently used it on a laptop at home with 4 GB of RAM, it crashed on me literally (just the tab, not whole browser) every 5 min with 2 tabs at most. Floorp (version based on Fx 148) at work today randomly decided to crash on start (plenty of RAM free).

To say I'm frustrated over the state of modern web browsers in general is an understatement. So far, nobody demonstrated that implementing e10s would solve all our problems, more like replacing one set of problems with another.

[mittorn]

I get why someone would want to try implementing e10s, though. It would help take advantage of multi-core processors more easily. Though I will say, if I wanted to do it, I would not do it the way Mozilla did it. Instead, I'd probably attempt to do it in a way that preserved XUL compatibility a bit better. Like for instance, having a root window process that uses the user's browser theme, along with any extensions that purely impact the GUI and avoid touching web content.

Most benefit it gives is browser UI is being responsible while content is busy.
But do we ever need separate process for it? When we are using OMTC+APZ, rendering/compositing/input is already done in separate thread (not really for input, but i implemented it in SDL port).
Both chrome and content process runs in main thread. We already support many operations in separate threads (workers, service workers, etc).
Can we use separate threads for chrome or content rendering?
Even if we only run chrome in separate worker, this would allow switching tabs or navgating menu while content is busy. This might be very helpful for APZ.
If we run content instances in separate threads, this will work as e10s, but may share some resources
Yes. making DOMs work in separate threads might be not much easy, but if we need responsible browser, optimal for multicore systems without all e10s hacks, that would be best solution

[Basilisk-Dev]

This is a bad idea. IMO you'd be better off implementing a new multiprocess system rather than re-adding the e10s junk that Mozilla had when we forked. Good luck and I hope you figure it out.

[UCyborg]

Could there be much more to fast JavaScript crunching than just multi-process? That part certainly prevents hiccups and additional slow down, but otherwise doesn't improve base speed. SeaMonkey could still get notably higher scores on Speedometer and generally felt a bit more fluent last time I tried it compared to UXP. And classic extensions still break left and right with e10s, like what I remember from trying roytam1's Serpent years ago.

[Basilisk-Dev]

Could there be much more to fast JavaScript crunching than just multi-process?

There are almost certainly places in a codebase as large as ours where multithreaded performance could be improved without introducing a full multiprocess implementation.

I've been experimenting with this different areas of the codebase looking for improvements. For example, locally I browse on an architecture with no JIT. I've been changing this code in local builds from 1 to 4 (so 4 helper threads instead of 1) and haven't noticed any issues yet: https://repo.palemoon.org/MoonchildProd ... hreads.cpp#

JITLess build means no WASM so I wasn't as worried about it there.

There's an obvious warning there explaining why we shouldn't do this so we wouldn't want to upstream that change but the difference is somewhat noticeable on my local builds.

[UCyborg]

Is it this part?

Code: Select all

size_t
GlobalHelperThreadState::maxUnpausedIonCompilationThreads() const
{
    return 1;
}

Is there a build flag for JITless build you put in .mozconfig?

[jobbautista9]

Is it this part?

I think it's more GlobalHelperThreadState::maxParseThreads, specifically the return below a comment block (which seems to be the warning that Basilisk-Dev mentioned). maxUnpausedIonCompilationThreads is related to Ion which is part of JIT.

Code: Select all

size_t
GlobalHelperThreadState::maxParseThreads() const
{
    if (IsHelperThreadSimulatingOOM(js::oom::THREAD_TYPE_PARSE))
        return 1;

    // Don't allow simultaneous off thread parses, to reduce contention on the
    // atoms table. Note that wasm compilation depends on this to avoid
    // stalling the helper thread, as off thread parse tasks can trigger and
    // block on other off thread wasm compilation tasks.
    return 1;
}

Is there a build flag for JITless build you put in .mozconfig?

I don't think there's a build-time flag for disabling JIT. Either the support code is added for an architecture or there's no support at all. In run-time however you can disable JIT entirely for webpages by toggling javascript.options.baselinejit in about:config. It's also an option in the Pale Moon Commander extension's Performance => Javascript tab.

[athenian200]

Yeah, more to the point, I do think in some places our codebase are still very single-threaded and doesn't take advantage of multi-core architecture, and that's why the "stupid half-busted e10s trick" as I like to call it, still helps some of the more... umm, adventurous users with stuttering more than we'd like. I feel like better use of multithreading and scheduling threads would likely help mitigate the "advantage" of using the browser this way somewhat, but we have had to put most of our development effort into things like keeping up with web standards or dealing with regressions introduced by newer versions of things, so actually making the experience smoother or more responsive has taken a bit of a backseat.

Like I can definitely imagine that trying to add more thread-level parallelism in the JS engine in particular would help, but there is some anxiety about making sure everything is wired up to handle that, and also that it's handled well/securely.

EDIT: Looking at the comment above by Job, didn't we see some changes from Mozilla while we were implementing WebComponents that mentioned changing the way the Atoms are handled in order to allow for more stuff like this? It might be one of the patches G4JC either slipped in because it was a prerequisite for changes we needed, or one that was rejected for being out of scope, but this looks familiar...

[jobbautista9]

SeaMonkey removed the limit in maxParseThreads in their own Mozilla fork: https://gitlab.com/seamonkey-project/se ... .cpp#L1179

Blaming it points me to bug #1431353, which pretty much depends on a per-zone atom cache added by bug #1350760, and this solution to the dining philosophers deadlock (related to wasm) in HelperThreads by bug #1379814.

[athenian200]

SeaMonkey removed the limit in maxParseThreads in their own Mozilla fork: https://gitlab.com/seamonkey-project/se ... .cpp#L1179

Blaming it points me to bug #1431353, which pretty much depends on a per-zone atom cache added by bug #1350760, and this solution to the dining philosophers deadlock (related to wasm) in HelperThreads by bug #1379814.

Good research, Job!

Yeah, that was it... BZ 1350760. I definitely saw that one referenced during the WebComponents migration on IRC ages ago. G4JC mentioned it and thought it would be good to pull it in, but the... umm, guy overseeing the whole WebComponents endeavor at the time kind of dismissed it (understandably) for being irrelevant to the core issue of WebComponents without encouraging him to open another issue for it. We were all so laser-focused on WebComponents, particularly Custom Elements and Shadow DOM. There were a lot of times we'd be hunting through Bugzilla and find a lot of slightly off-topic things that looked potentially good to pick up, and then drop them on the floor without ever filing another issue because it felt like there would be a lot of "red tape" so to speak, plus we were already doing so much work rushing to get WebComponents off the ground.