e10s support question

[Basilisk-Dev]

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.

That is it. I had the line number there when I pasted my link but I guess phpBB didn't like that.

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

No, I'm currently using a LoongArch system for my desktop and an Apple Silicon Mac for my laptop. Neither of those two CPU architectures has JIT support so the browser always runs without a JIT.

[UCyborg]

OK, so don't need to turn off JIT (x64 Windows machine), just WASM, which I don't need often. Looks good so far, just didn't have much time to really evaluate. I'd almost say it's quite noticeable (I made it return cpuCount), but I'm not sure if memory recalls slower responsiveness in this one particular client-rendered web app at work from the browser running for a while and getting slower with runtime or was it like this from fresh start.

Off-topic:
Oooooh, I noticed Jenkins is quite a bit more colorful with this development version of Pale Moon (https://forum.palemoon.org/viewtopic.php?f=70&t=32709). Sweet!

[jobbautista9]

Perhaps we can make a pref for what number GlobalHelperThreadState::maxParseThreads returns (with the default -1 being cpuCount)? Maybe guard against the pref for enabling WebAssembly too.

[Moonchild]

As an aside, to demonstrate the issues with e10s, current release cycle Firefox security bugs that I just went through had 45 of the bugs I looked at directly related to e10s. In just this month.
That's not counting issues that are less obviously prima facie caused by the e10s architecture of Firefox. Keep in mind how long ago this was introduced in Firefox, and we're still constantly having security issues in it every single month. It was supposed to be a "more secure" way of handling web content, remember? Because web content would be limited to its own less-trusted processes. Turns out it's suffering from exactly what I said, in that the messaging protocol itself is vulnerable to attack in ways a single-process browser would never have exposure to.

[ownedbywuigi]

current release cycle Firefox security bugs that I just went through had 45 of the bugs I looked at directly related to e10s. In just this month.

Does Chromium or other engine’s multiprocessing implementations suffer from the same issue, or is it JUST Firefox which is dealing with these countless bugs?

[Moonchild]

Chromium suffers from the same.

[Martok]

It's a bit off topic here, but if something is to be done against the freezes and virtual memory leaks, that time would be better spent on the garbage collector.
I've tried investigating this multiple times over the years, but the furthest I've gotten so far is that at some point the trace graph becomes complicated enough that the incremental GC does not get anything done before some action will upgrade the collection to a full GC anyway. And since it is a stop-the-world collector... well, it stops the world. What I'm less clear on is why even when collection finally finishes, the compacting doesn't really work at all (simple test: open youtube, wait a bit, close the tab, compare about:memory to virtual size). That makes me think major fragmentation on the jemalloc side of things, which then wouldn't be great for new allocations.

[ownedbywuigi]

It's a bit off topic here, but if something is to be done against the freezes and virtual memory leaks, that time would be better spent on the garbage collector.

Noted, will try to spend some time optimizing that in either Dactyloidae 13.1-pre3 or 13.2 for up-streaming.

[UCyborg]

TBH, PM still feels rather slow and laggy with my regular usage with maxParseThreads set to cpuCount.

[Basilisk-Dev]

TBH, PM still feels rather slow and laggy with my regular usage with maxParseThreads set to cpuCount.

It's substantially faster for me on non-JIT builds. I'll need to test an x86 machine later.

[UCyborg]

It's just that things get slower the longer the browser is used. I cannot avoid this to get things done in real life.

[Basilisk-Dev]

It's just that things get slower the longer the browser is used. I cannot avoid this to get things done in real life.

Are you saying it's getting slower with the helper threads adjusted or just in general with or without that patch? The reason I ask is that I am backporting a few Mozilla changes to improve performance including this one, and don't want to submit a PR if it's slowing people down.

[UCyborg]

In general. I don't think the patch by itself is bad, it just seems to be a small part in the bigger picture.