Improving Firefox stability on Windows by retrying failed memory allocation
hacks.mozilla.org
hacks.mozilla.org
I had abandoned Firefox entirely on MacOS until sometime I decided to try again and it was no longer attempting to claim an entire 32GB memory for itself. So, I am back as a happy user :)
In a nutshell we're directing the OOM killer towards less interesting processes within Firefox so that when the system is low on memory they'll get killed first. This not only makes it more stable overall but it plays nicer with other applications too. Web pages that leak memory in the background are particularly likely to be killed by this mechanism and that alone is a huge improvement in overall stability.
I usually keep an eye on the memory usage I have displayed in the taskbar, and have sysrq activated in case. I tried multiple things, including avoiding swapping to disk (only using zram), and Zen kernels. I'll have to see if I use MGLRU.
Check out `about:memory` and `about:unloads`, the former has memory minimization options and the latter lets you unload background tabs from memory.
Have you compared it with the default Hibernation (Tab Unloading) recently? I don't use any extensions apart from UBlock Origin since I lost trust with extensions after seeing a recommended FF extension promoting scam.
When compared to Vivaldi's default hiberation(Where I have to manually trigger bg hibernation every now and then), FF's hibernation seems to do its thing (about:unload) quite well.
We are now in an age that think software bug is a norm. It's respectable that mozilla still keep the standard as high as the past days.
But in all seriousness, I can't recall the last time FF crashed on me. My OS hard locks more often than FF crashes.
I've also never seen the memory issues described here. But then I don't leave a lot of tabs open: it's rare my tabs don't fit in the title bar. I think that pattern is true for most people: almost all our fleet had very few tabs open. So perhaps the fix, while welcome, doesn't effect most people.
For a while it used to be kind of slow on Mac and Linux, but I think that was slow graphics calls, which points to a possible issue with the graphics driver I was using. But the last time I checked (many months ago), it was much better.
Perhaps not FFs fault, could be an underlying driver issue, but ideally web content is sandboxed enough that it can't bring down everything.
I once saw a unity web game with a bug that crashed all major browsers across multiple OSes. Go go web tech!
I was pretty much forced to install the Auto Tab Discard extension, which I'm guessing was built-in in Opera 12 ??
So, you know, anyone who opens a story on Ars Technica to read later and then forgets about the tab.
I've seen YT do similar things in the past as well.
I hope I described how this whole things work because Windows memory management is not well known and some things about it are counter-intuitive; especially if you're coming from Linux.
I have 17 crashes on file (in about:crashes) that are OOMs caused by Firefox committing too much memory and not using it. My solution is to restart the browser when committed memory reaches 38GB or so, but that clears all private windows which annoys me. I shouldn't have to restart the browser so often.
As for opening a bug on your tracker, meh but I can give you a list of report IDs:
bp-e6392a4b-44e8-4013-a80e-1027b0221109
bp-dae0a056-3c6a-43ea-ad3f-5fe1a0221006
bp-0be1e0f7-0eca-4744-a05c-ce2030220927
bp-65c63eea-fb45-419d-a58a-82ef20220915
bp-061b6131-5ae3-4de1-a7ba-0c4950220830
bp-32f879a0-f76f-4a5b-bef9-f013f0220820And yes, my page file had grown to 64GiB before, when I stupidly left it on automatic. There's a reason it's at 16MiB now - it's because completely turning it off disables memory compression. Not like that helps much due to the lack of overcommit.
This is how Windows behaves by design, there's nothing we can do about it. Windows without a swap file sucks.
Before, when I killed Firefox (before it crashes naturally, of course), my committed memory would drop from 38GiB to around 18GiB, so uhh, unless some other app is intentionally playing with me and syncing up its memory leaks with Firefox's existence...
(Plus, Process Hacker confirmed that all of Firefox's "Private bytes" added up to about how much committed memory got freed when I killed it. Explain how that is caused by memory fragmentation!)
This is my third conversation with a Mozilla engineer about this! Always looking forward to be proven wrong, but it looks like you just can't seem to find the problem yet. I hope one day you can. :)
It seems unlikely given this exchange, as you seem to have decided to be as unhelpful as possible.
> Before, when I killed Firefox (before it crashes naturally, of course), my committed memory would drop from 38GiB to around 18GiB, so uhh, unless some other app is intentionally playing with me and syncing up its memory leaks with Firefox's existence...
From the article:
> However, we have no control over Windows system libraries and in particular graphics drivers. One thing we noticed is that graphics drivers commit memory to make room for textures in system memory.
Guess what's going to create textures which might trigger such an issue? The browser's hardware acceleration. Guess what happens to browser's textures when the browser is killed? They're freed.
Might be a bug in Firefox, might be a bug in the crash reporter, might be a bug in the driver, might be that chromium is not using hardware acceleration.
But here you have a mozilla engineer specifically working on crashes, and instead of trying to work with them (possibly off-board) and with the data they have to diagnose the issue — because I'd assume when gsvelto talks about commit space contents that's what they see in the crash reports - you're just being a snarky asshole.
I'm not being unhelpful on purpose. They are just giving me answers that do not solve my problem. My problem is "Firefox requires overcommit to run for long periods of time ... because it has a memory leak". The solution to this problem is to figure out where the memory leak is coming from, and fix it, right? Not just to add more memory, even if it is only virtual memory.
> Guess what's going to create textures which might trigger such an issue? The browser's hardware acceleration. Guess what happens to browser's textures when the browser is killed? They're freed.
You just described a memory leak, yes, the exact issue that I am experiencing.
> Might be a bug in Firefox, might be a bug in the crash reporter, might be a bug in the driver, might be that chromium is not using hardware acceleration.
Well, I don't think the crash reporter or Chromium are at fault. And I know Chromium is using hardware acceleration because if I choose the d3d11 backend then Netflix goes black in screenshots due to DRM. So, if it is a graphics issue, it's something that Firefox does and Chromium does not. Which leaves Firefox bugs, or bugs in the driver that only Firefox triggers.
> But here you have a mozilla engineer specifically working on crashes, and instead of trying to work with them (possibly off-board) and with the data they have to diagnose the issue — because I'd assume when gsvelto talks about commit space contents that's what they see in the crash reports - you're just being a snarky asshole.
I'm sorry that I came off as a snarky asshole and that wasn't really my intention. I've been dealing with this issue for months, and as a result of that there is a lack of effort from me and that probably shows. I am sorry.
I would like to perform some more experiments to figure out what the issue is, but the problem is that when Firefox runs out of memory it also crashes half the other things on my system, which makes it dangerous.
Kinda the opposite of what I'd want; I usually have over 16GB more that Firefox could use if it needed, and that's once it has reached critical mass with maybe hundreds of tabs.
Its memory measurements usually look sane, so I feel like there's some data structure or algorithm that is doing something insane in the background - which is already confirmed to be the case with the History menu, particularly if you select and delete thousands of items at a time.
Circa 2021 if I wanted my MacBook to go to sleep I had 5o shut down FF first.
FWIW wasn't any better on windows.
Also, more sites just don't care about having their stuff work in firefox. I use chromium for roll20, because there is just a lot of things that are just broken on firefox.
Same here. I will pay for an alternative to Roll20 that works on FF. Bonus points for open source with a hosted version.
Disclaimer: I've basically never used roll20 because it's way too heavyweight for my games; I use Owlbear Rodeo instead. But I have tech-savvy DM friends who use and like Foundry
Thanks for the pointers!
This is also a good example of the benefit of telemetry: that they have crash numbers coming back from the field lets them tell that this really did work in practice and get a sense of how much of the problem they've solved.
* telemetry is evil
* if the product is free (Firefox), you are the product
It seems Firefox executives take a large chunk of money from Google; presumably to make sure Firefox doesn't do anything too wild that would reduce Googles income.
I wonder how much of what the Tor Browser version of Firefox does, would be upstreamed to Firefox proper, if not for that deal?
(I wonder how much the Firefox team considers Tor Browser to be "the real Firefox" / "Firefox the way we intended", with Firefox itself just being "the sell-out version of Firefox"?)
Firefox is my union representative. They are better able to fight for my interests against Google than should I go it alone and use Chrome.
Its not a perfect system, but it should somewhat work.
But many of us who used it from the start think it was a much better browser before. For a long so much was sacrificed for next to no improvement.
For me it was more or less rock solid at >800 tabs and with a lot less memory and more exciting extensions than I have now.
I admit this wasn't everyones experience, but as a superuser tool it has degraded a lot over the years.
That said it is still the best browser for me: I don't think anyone else except Orion (which is Mac only) has actual tree style tabs (not to be confused with vertical, non indented tabs as seen in Opera derivatives).
The benefit can be claimed only if the user consented into their private information being shared with the browser vendor in the first place. With most browser telemetry that is not the case and browser is simply not respecting users' privacy. The right to privacy, as a human right, trumps the 'right' to have the product 'improved'.
Otherwise we can find "benefit" in everything. One of the benefits of hell, for example, is that it is never cold.
But since the product is digital they just have to give it away blind? Never knowing if people even use the features or not?
So if software is a tool and my drill is monitoring the holes I make in stuff and its efficacy in doing that, that seems fine, but if the drill is sitting in my toolbox being a busybody and sending back everything it can find about me from within the toolbox, that drill is made by assholes, don't you agree?
That seems like an unfitting comparison. The problem doesn't arise in the store, but when using the product at home. The equivalent of store cctv in this comparison would rather be a server log on the Mozilla website (where people get the product). It's fine to do telemetrics there without me consenting (as long as it's only used by first party) if you ask me. But after I leave their premises it's none of their business how I use the product.
Sounds like you want it to be ok that your newly bought pack of condoms sends out a message to the factory once you open one.
Not to mention that Firefox is open source, so you (and GDPR authorities) can check yourself what exactly is being sent...
Even if that was not the case, a privacy respecting (any?) browser has no business whatsoever sending any information from my machine, including "I crashed because of OoM" or "I clicked button X" unless I consent with it doing so.
Therefore zero telemetry by default is the only acceptable standard for any browser that claims to be privacy respecting.
For what it's worth, I have no issues with telemetry as long as they are opt-in and there is transparency on exactly what is collected.
It's having to opt-out (or not being to opt-out at all) and vague explanation on what and why there is telemetry that I take issues with.
Crash logs are a different beast.
And very biased towards what? People not triggering bugs?
opt-in telemetry is effectively the same as no telemetry.
if you have (or anyone has) a problem with crash statistics being tracked via telemetry then I have absolutely zero idea how to convince you that it's a good idea that this blog post doesn't already clearly state.
it's the same with OS updates; people (generally) simply will not perform system or security updates unless they are forced, because everyone thinks they are smarter than the "script kiddies" who would use an attack against them. the user thinks they would see an attack coming and avoid it. in short, they don't. viruses spread, the US Congress calls Microsoft in and asks why the systems weren't patched, and Microsoft says "the users are responsible for patching" and Congress doesn't like it.
so now we are where we are. OS updates are forced after a time, and telemetry is not only the norm, but a very good idea for applications in use by millions of people, like Firefox.
Updates were not the default. And when they became almost mandatory Microsoft started bundling "features" with security updates. That's when people started to disable this "feature".
> so now we are where we are. OS updates are forced after a time, and telemetry is not only the norm, but a very good idea for applications in use by millions of people, like Firefox.
And this doesn't change anything. Ransomware attacks are still the norm.
[1] https://www.cio.com/article/274775/it-organization-luser-peb...
My tone here is borne out of users shooting themselves in the foot and then complaining about the pain and inability to walk. At every opportunity that I have taken to give computer users the choice to do the thing that is good for them, the overwhelming majority have failed to make that choice. The people who visit this site are mostly not that kind of person, though there are plenty here who are.
We have shown Microsoft that we simply will not update our operating system or even reboot unless forced. Many, many times we have made this clear, even though patching is overwhelmingly a net positive for both MS and its users, generally speaking, users simply won't do it. They just won't. History bears this out.
Updating is a short-term inconvenience in exchange for long-term security and stability, and people do not think about those things logically. The importance of the immediate future is amplified by a large factor, and the importance of the future is attenuated by a large factor, in most people, especially when it comes to people who view their computer as a tool. Sitting in front of a computer is indicative of a user wanting to complete a task, and manual updates impede the ability to perform that task. That makes installing updates and stopping work to reboot a non-starter for those people. They just won't do it.
I don't know how else to say it. It's not a matter of tone so much as it is a matter of fact.
> My tone here is borne out of users shooting themselves in the foot
Frustration. I hear you. Sure, it's frustrating that they exercise choice (however misguided you see that) and then "complain". It's very nice if you've written code, and even nicer that you care for your customers. But, as developers, they aren't our children. I've been there and it's galling, and feels like a rejection, but to accept what is unrequited is sometimes harder than giving it.
> the choice to do the thing that is good for them,
This is the elitists' dilemma. Please don't be insulted by that word, I'm using it literally and appropriately without value judgement (I am foremost an elitist, and secondarily a peoples' champion, and it is a position that can only ride on a measure of arrogance - which must be tempered)
The fact is, it's not your computer. And that really is the long and short. One must respect that if "users" do not wish to take advantage of bug fixes more speedily available through telemetry, then it's their choice to have suboptimal, buggy programs.
In other news, our children will listen to shit music and get into drugs and relationships we disapprove of etc.
> We have shown Microsoft that we simply will not update our operating system or even reboot unless forced.
For very good reasons. Microsoft have shown themselves to be utterly untrustworthy. I really don't think that's even debatable. And it's a shitshow because I do not believe trust can ever be repaired. It leaves the reality that one of the biggest vendors on the planet is in the position of forcing users because it has squandered the reputation necessary to do good-faith business, to propagate its updates. That's tragic because they probably see no way out except doubling down on abuse, authoritarianism and beating users to their will - and ultimately that confrontation will be the end of so much we have built.
What makes this worse is that security is about more than personal choice (think vaccinations). In other words the damage that Microsoft (and other big-tech abusers) have done goes far beyond simply destroying the individual trust relations with their customers. They've corroded the social fabric of trust in computer security at a more general level - a cost that is incalculable.
> people do not think about those things logically.
You are right. And we should not assume that they should. Emotion is a powerful reasoning tool, and only a fool ignores that force of psychology. Once burned twice shy - and we as developers have been burning a lot of peoples' fingers these past 30 years.
> I don't know how else to say it. It's not a matter of tone so much as it is a matter of fact.
I see it means a lot to you. That is a good thing in itself. You care, which is x10 above the norm.
But we cannot force them to be what we wish them to be. Especially not "for their own good" which is where all tyranny begins. We cannot force people to adopt products, customs, behaviours, sing the party line, or any of that hegemonic nonsense without invoking an age of "consumer communism".
It saddens me that in 2022 we still need to address the patrician attitude. It's not the way forward. It's sad to see such a deterioration. But so long as companies like Microsoft persist a culture of smug superiority, cavalier conceit and intransigent disrespect to the dignity of their users we will have to accept "fuck you" decision making. And frankly, more power to those courageous enough to say it.
No. People do not perform system updates because a) it's a chore and b) it get's in the way or even breaks things. To do an update I need to agree to give up control over my device for some time (often undetermined) and then risk that updated code causes issues (it's not uncommon). We need to design apps and operating systems with seamless and reliable updates in mind, not force people to suffer.
That's an indication that people don't want this.
It's an indication that optional steps which do not immediately benefit the users of the software will not be taken.
The benefits to telemetry are longer-term, and because opting in is not required for the software to function, the vast majority of users simply will not do it. The thought to turn it on will likely not even enter their mind. Why would it? The software works fine.
Opt-in telemetry was tried by just about everyone that collects telemetry today. Lots of people say they will turn it on, and then never do. Telemetry is used to make better software. I'm sure there are companies that use it for [insert activity that any person might perceive as bad] and I would argue that those companies would likely not allow you to opt out.
If people understood the kinds of things that are collected, at least the things I collect in the software I write for work, I can't imagine anyone having a problem with it, but there's a lot of things that people do which make no sense to me at all, so I'm not really in a position to be authoritative.
I do know what happened in the late 1990s and the early 2000s though, and I know those things are a large part of why telemetry and forced updates are things which exist today.
I believe that absolute vast majority of telemetry is simply ignored. And I also believe it is very common that there are several individuals in most companies that couldn't care less about what is included in the telemetry.
A lot has changed since the late 90s, it really isn't good argument for telemetry nor forced updates that things were bad then. Things would have been absolutely awful in the late 90s even if you had perfect telemetry and instant updates that somehow didn't even need internet.
I don't see any real arguments for either in your posts.
Regardless of how strongly you feel about telemetry and its perceived "benefits", the choice should always rest in the hands of the individuals using the software first and foremost. Your customers should always be informed of their choice and if they feel like they are willing to participate, they can opt-in.
How would you feel if building architects decided to install a camera in your bathroom in order to analyze how you use your toilet and the shower to assist in improving future constructions?
> Lots of people say they will turn it on, and then never do.
Because most of the time, there is no benefit. The software is already made, and further development is rarely informed by telemetry data. Furthermore, customers are rarely informed exactly what data is being collected - and not given the opportunity or benefit to inspect the contents of any telemetry or crash logs that need to be sent.
> If people understood the kinds of things that are collected, at least the things I collect in the software I write for work
But they don't. And no one takes the time to educate or inform them or give them the choice to opt-in with a detailed disclosure of what is being shared, rather than having to opt-out. As people become more aware of these telemetry practices, you're going to see a wider backlash at the kind of unnecessary data that are being collected. Maybe you're not doing it - but others are.
There are other ways to test software... Especially the use-cases mostly used by users not well versed in the tech world.
I was under the impression that Firefox was written in Rust. Doesn't this eliminate crashes? Rust is a safe language after all. There should not be any crash logs with Rust.
That also said your parent equating memory safety to “no crashes” is also not correct. A process can exit early while never violating memory safety.
Rust has a `panic!()` macro which will hard-terminate the program and log a stack trace in what is functionally equivalent to a crash. It can be called in various scenarios... including out-of-memory situations (like the ones being addressed in the fine article and this thread).
This service would be guaranteed to be unidirectional, would store data publicly on non-profit-run servers and domains and fully comply with GDPR (by not storing any PII and ano/pseudonymising everything).
Developers would connect to this service over dbus and consume the uploaded data in daily batches.
Hosting and hardware fees would come from donations by distributions and other organizations distributing money to the FLOSS ecosystem.
Love the idea!
There's nothing stopping a person from creating that. You'd package it up and get it added to the Debian, Ubuntu, RedHat, etc. repos and people would be able to install and use it. That's about as close as you'll get to having it generally available for all Linux distros.
Personally I don't see the value, and think it's invasive, so I would never install it, but people who wanted it would be able to use it.
The telemetry proxy service would need packages for each distro, including scripts to work with systemd and init, and maybe a "libtelemetry" package to make using the service easier.
The way I see it working is that if the system service isn't installed, isn't running, or has remote telemetry turned off then the commands for sending telemetry will succeed but send the data to /dev/null. Otherwise the data gets anonymized and uploaded to the user's configured telemetry host.
It could almost be built on syslog, now that I think about it more, but that would be terrible.
This page from Debian Wiki may be interesting to see what all is out there: https://wiki.debian.org/PrivacyIssues
I enable it on my personal production systems and disable on everything else, both on privacy grounds (work), and not providing wrong data (disposable VMs).
This is the right approach.
Privacy should be privacy by default, and if you want users to send you crash/usage logs then you need to show them all of the dirty details, let them review it and chose whether or not to send.
https://probes.telemetry.mozilla.org/?search=crash shows automatic telemetry probes. The main bit of data in that set is FX_CONTENT_CRASH_* and you can see the back and forth from the data steward and the engineer adding the probe. https://bugzilla.mozilla.org/show_bug.cgi?id=1269961#c8
What in that report is creepy? Surely knowing the percentage of people on 32- vs 64-bit isn't problematic. Maybe add-ons? I'm genuinely curious.
Next thing you know they might try to increase engagement time like they're some sort of social network. "Unlock the new exclusive colorway by logging in 30 days in a row." seems like something that could be implemented, seeing how they're time limited already.
Usage times and intensity are of high value when trying to improve market share. People who barely use the browser are at high risk of stopping use altogether. (For example, they might use multiple browsers, but most of their activity occurs on another and if they figure out multiple profiles or something, they'll leave altogether.) You can't do an A/B test to see what improves usage intensity if you don't measure usage intensity. Also, it's far from PII. And making it opt-in would make the stats useless; people who explicitly choose to allow telemetry are going to have vastly different usage patterns than the bulk of people who do not so choose.
Extensions are very important for crash reports. Far less than they used to be; many crashes could only happen when an extension did something specific. Extensions are now sandboxed enough that this isn't nearly as common, but if a crash signature has a high correlation with a particular extension, it can easily turn a non-actionable bug into something actionable.
Extensions for general telemetry are iffier. The info is fairly high value for things like understanding how people are using the browser and what features are popular or missing. But rare extensions also provide a lot of fingerprinting info. It's important to keep those metrics away from PII, and recorded independently so they can't be correlated.
Country of origin is pretty clearly useful. Mozilla has to allocate resources across countries, including marketing resources, but I would think it's really product management where it matters most. Users gain a lot of benefit from the browser adapting to different markets. (Screenshots have a wildly different importance in countries with Asian writing systems; Europe and especially Germany take privacy much more seriously.)
> Next thing you know they might try to increase engagement time like they're some sort of social network. "Unlock the new exclusive colorway by logging in 30 days in a row." seems like something that could be implemented, seeing how they're time limited already.
Heh. I do not want to predict what our marketing people will or won't do. I have mixed feelings about quite a few things. I'm not happy about ads appearing anywhere in the interface. But I'm also not happy about being dependent on Google ad money.
How about the profiles of the people who opt-out?
Second, it's fair: if you disable telemetry, you're choosing to not be considered in any telemetry-backed decision making. If you want to still be considered, then it's up to you to make your opinions heard in some other way. (Filing bugs or https://connect.mozilla.org or discussions in places like here, though note that the latter is mostly useless. Not many Mozilla people read this forum or take what is said here very seriously. And even if they do people will be vigorously arguing both sides so it's easy to pick the side you already agree with.)
There's nothing wrong with disabling telemetry. I respect the decision, and I'd certainly rather have people using Firefox with telemetry disabled than have those people not use Firefox. But it's your browser, and even the social contract by which you're using it doesn't say you owe us telemetry data.
The "make it hard to find" to "nobody uses it" to "let's delete it" pipeline is very real. Reminds me of the "defund it" -> "it does not work" -> "let's privatize it" pipeline in right-wing governments.
As a larger piece of the visible audience, I then hope that more attention is given me. This is especially important for open source projects. And I don't care that much about what the company is getting from me.
But listen, they collect all sorts of stuff and you should disable it unless you understand it. Ideally, privacy laws expand to the point where you need to email a signature saying you understand before you opt in to telemetry. Informed consent is required for any reasonable study.
> Telemetry is the in situ collection of measurements or other data at remote points and their automatic transmission to receiving equipment (telecommunication) for monitoring
> Wiki https://en.wikipedia.org/wiki/Telemetry disagrees
It feels like your response fails to address the point colejohnson66 is making. They are saying "some spying is done via telemetry, but not all telemetry is spyware." The automatic nature of it is orthogonal to its spy-ness or user hostility.
Basically, "automatic" here is an antonym to "manual" e.g. user emailing a bug report.
Personally, I consider the following sorts of telemetry "not spyware":
- coarse grained crash report (build version, arch, etc). this is usually a manual prompt on crash, so "semi-automatic telemetry" is how I'd define it
- anonymized metrics/spans. Basically "foo_bar() took 20ms". These are "automatic" in that the collection and transmission happen without user input, but that's orthogonal to whether the user opted in/out.
Fine-grained usage information is a lot more spyware-esque.
Chromium developers hate him!
I suppose it technically improves stability, but the cause seems like a flaw in the Windows operating system, if I'm understanding correctly.
> Stalling the main process led to a smaller increase in tab crashes – which are also unpleasant for the user even if not nearly as annoying as a full browser crash – so we’re cutting those down too.
I wonder if this has anything to do with my recent experience with Firefox Nightly on macOS. In the last few weeks I started to experience spontaneous tab crashes that couldn't be explained by anything from what I could tell. I could open a new tab with the exact same page and it would manage to not crash. Then I noticed Firefox would sometimes prevent me from viewing tabs until I restarted to update the software. Haven't seen it in the last few days, but it was incredibly frustrating. IMO, Firefox should make a best effort to render a page and not have its core functionality stop working entirely until updating.
Where is the blame?
Maybe Firefox is too bloated or memory-inefficient. Maybe Mozilla didn't understand Windows's memory management strategy until now.
Or maybe Windows is too bloated and memory-inefficient. Or maybe the memory management tradeoffs were suboptimal.
Or maybe nobody is to blame, and they are taking advantage of something in a novel way that allows them to squeeze more juice out of the same fruit than others.
Not sure, but sound stopped working in VLC about one year ago and was restored this month at the same time that dropping files stopped working. Every time after a Windows update and with the same VLC version.
I don't think Windows is too bloated or memory-inefficient, but I do believe that they're abusing the AV and "monitoring" stuff. It's a cat & mouse game, with me trying to disable crap and they re-enabling it with every update or simply making impossible to disable annoyances.
Also I suspect they're trying to "fix" drivers that worked before the fixes.
You know I used to be on that boat up until very very recently. I have a 2019 HP Stream 10" with 32GB eMMC and soldered 4GB DDR4. Windows got it bricked on a botched update, so I installed Linux Mint to get it back up quickly.
Not only is Linux using a lot less storage (which was always and issue with Windows Update), but the RAM usage is about 700MB without any applications running, and well under 4GB for most common uses. Sure, Chrome(ium) will eat a hefty chunk of it when you run it, between zram-config and some extra swap space, it handles things a lot better than Windows ever did.
Antoher point of anecdata: shared libraries are actually shared a lot more between processes on Linux than on Windows. That tends to mean a lot less RAM usage on certain process. I know it's down to how they handle sharing things and that Windows takes the "safe" approach (pretty much what the article talks about!) but it ends up hitting memory a lot more than Linux and macOS.
Forcing the application developers to be cautious is just changing who needs to be safe, because reducing problems for your app while increasing overall system instability is still bumping up against the issue at hand.
It is sort of like how someone might be upset with speed limits, but the people who set the speed limits aren't thinking about your particular desire to get to work today, but the overall flow of traffic and public safety needs.
I realize linux still has out-of-memory handling and various safeguards in their memory management, but it is sort of like arguing whether to set the speed limit at 50 or 60. Nobody is actually right, it is just different preferences.
If the swap were allocated to the whole HD that wasn't used for actual files, then this hack wouldn't work.
If the swap were leaner that it already is, this hack would be necessary in every program.
If I had to point a finger at who is to blame, it's the Windows swap allocation team. Some combination of predictive analytics or even just a saner ratio of swap to free HD for an incoming file would fix this problem for most users most of the time.
But computers are hard and people want to keep them running for days on end. I get that memory just slowly, slowly gets eaten up by all the zombie procs out there.
Then the hack wouldn't be neccesary as they'd have far more committed space to waste
> Maybe Mozilla didn't understand Windows's memory management strategy until now.
That is part of it. A lot of FLOSS engineers come from a Linux background and tend to assume that the Linux way of doing things is the "normal" way. While I was there I had to explain to more than one developer that Windows doesn't have an OOM killer because the NT kernel doesn't overcommit.
I thought it was possibly related to ff on ubuntu switching to being a snap by default (even though I thought I had forced my system to have no snaps and no snapd and added a special ppa for ff) and said something in a comment on hn, and several people clued me in it's way older than that and I'm not the only one who hates it.
It's like ff devs don't actually use browsers, which is crazy of course. But, they really are ok with always having to blow away everything ypu have going at any random time middle of the day? (it's always someone's middle of their day or stretch of involved work)
They never have tabs open with partially filled forms or search results or web apps that "restore tabs" won't restore the way they were? Or this just doesn't bother them?
It feels like a case of "you're holding it wrong", as in the user should shape their usage pattern around ff's update strategy, like, always do and apt upgrade before sitting down, and never after starting to work, and if you leave tabs and work open over night, well I guess just don't do that?
Y'all don't get your tabs restored when you restart your browser?
For me, the restart experience pre-snap was very easy - close, re-open, and you're right back. Most 'serious' webapps will happily save your drafts if, for whatever reason, you don't want to finish and send that half-composed slack message before restarting.
It got much worse with the switch to snaps.
Ironically, the tab restore breaks when you open a new tab and it hits the "Restart required" page.
On restart, the browser found a clever way to maximize user frustration. It simply attempts to restore the "Restart required" page again (and fails), leaving the new tabs you tried to open blank after the restart.
I still have updates enabled, despite the "Restart required" page providing a strong push to disable them. But at the current rate I might give in eventually.
I addressed that.
Of course that also means you could end up having queued but not applied updates for a long time on Windows and macOS…
It's not a flaw at all, when you understand what is going on. Part of the issue is that in 2022 so many developers come from Linux backgrounds that they assume that the Linux way of doing things is the "normal" or "correct" way.
The NT kernel does not overcommit, and thus does not have an OOM killer. If the kernel cannot commit pages, the system call fails. That's it. No process terminations.
Firefox would crash because (even on Windows) it uses a customized version of jemalloc that is configured to be infallible by default. If jemalloc requests pages and those pages cannot be committed, the heap allocation will fail, and thus Firefox will self-terminate. That's simply a policy decision on Firefox's part.
Going back to Windows: suppose that the commit request failed because the swap file was full. Assuming that Windows was configured to automatically resize the swap file, the OS will then grow the swap file. That's why pausing for a bit and then retrying the VM allocation works: the swap file was grown, and now the pages can be committed.
Committing is limited by RAM plus swap. You’d have to reserve much more swap than is typically ever actually used by processes, at any given time.
But if the swap wouldn't actually be typically used, then what's the problem with that?
Especially considering that the amount of disk space required for that is cheap.
And why not let the user decide for himself if he prefers to guarantee that their applications never get killed by the OS at the cost of reserving some disk space that he probably wouldn't ever use anyway (as most filesystems' performance nosedives after >90% disk usage anyway).
With modern filesystems using delayed allocation to reduce fragmentation, and SSDs reducing the cost of fragmentation, you can often get good performance at higher occupancy nowadays.
SSDs certainly alleviate this problem, but even in SSDs, sequential I/O can be much faster than random I/O.
Anyway, I guess my point is that the vast majority of systems don't run with >90% disk space usage, so reserving up to 10% of the filesystem for swap space is not unreasonable.
Note that this would just be a space reservation. You wouldn't need to actually allocate specific disk blocks or write anything to the swap file, unless the system starts running out of memory.
In reality, you'd need much less than 10% (in the vast majority of cases), especially if you have a Windows-like API where you can allocate address space separately from committing memory (which means uncommitted address space doesn't need swap space reservation).
I'm not convinced that the fork()/exec() issue is the correct justification, at least not entirely. As an example, Solaris supports fork()/exec() yet it doesn't do overcommit (at least not by default, I think) and has no OOM killer. And Solaris has a long history of being a very robust OS.
Also, in most cases I don't see what is the problem with reserving more disk space for swap (disk space which would almost never be used anyway), especially if the system becomes more robust as a result of that.
I think I recall Linus justifying memory overcommit by observing that the vast majority of applications don't handle out-of-memory conditions gracefully, so it's better for the OS to kill a misbehaving process (that is allocating too much memory) and let the others continue working normally than have every single process in the system have to handle out-of-memory failures, which they don't usually handle gracefully. But I'm not sure if I'm recalling this correctly.
I don't think either the overcommit design or the naive "all allocated address space must be reserved" design is the correct approach. I know almost nothing about Windows memory management, but it sounds to me like having "commit/uncommit memory" system calls separate from the "allocate/deallocate address space" system calls to be a better approach.
But I think the OS should try to reserve more space for the swap file before it starts returning ENOMEM to the "commit memory" system calls like Windows seems to be doing (judging from the blog post)...
One could just as easily argue similarly with respect to Unix and needing to loop over write watching for EINTR et al.
I'm sorry, but I fail to see how that is related.
EINTR is useful so that you can handle a signal in case it is received in the middle of a very long system call. For example, if an application is doing a write() on an NFS filesystem and the NFS server is not reachable (due to some network outage), the write() syscall could take minutes or hours before it completes.
So it's good, for example, than you can Ctrl-C the process or send it a SIGTERM signal and abort the syscall in the middle of it, letting the application handle the signal gracefully.
What I'm talking about is not related because allocating disk space on local disk (where the swap file would be located) is generally a very quick process. Mind you, only the disk space allocation is needed for reserving swap space -- it's not necessary to write anything to the swap file. In fact, it's not even necessary to actually allocate disk space, but I digress.
And even if reserving swap space would take a long time, allowing the syscall to fail with EINTR would also work fine.
What is not fine is letting the application believe that the system has completely run out of memory when in fact a lot of disk space can still be used for swap reservation.
Fortunately, this is tunable. You can also turn off overcommit entirely.
https://www.kernel.org/doc/Documentation/vm/overcommit-accou...
I know, but as soon as I tried doing that, my systems started to experience unavoidable failures (although I don't remember exactly why, but I certainly don't think it was simply due to lack of swap space).
Again, I don't remember exactly, but I suspect I experienced these failures because there are applications that expect Linux to be doing overcommit, or at least, they couldn't work without overcommit unless Linux added new features.
I could be wrong (I'm not exactly a Linux memory management expert), but I think the root issue is that Linux is handling committed memory badly, because when you disable overcommit, Linux tries to reserve swap space for the entire allocated address space of all processes. But actually, this is not needed -- it's way too pessimistic and is extremely likely to lead to unnecessary memory allocation failures.
What is needed is a way for applications to communicate with the kernel about which parts of the address space they might actually use (or not use) at any point in time, which may be significantly less (by orders of magnitude) than the amount of address space that they have allocated.
Then you wouldn't need to reserve swap space for all the address space that processes have allocated, you'd only need to reserve swap space for the amount that the processes have declared to be (possibly) using.
This could have a performance cost, but there are ways to reduce it, for example, by allowing this information to be declared in mmap() as a flag (which avoids doing 2 separate system calls in the typical case), by batching several syscalls into just one (similar to readv()/writev()), by using io_uring(), etc.
I also think that, even if you want to use memory overcommit, then enabling overcommit should be done with (at least) process granularity, not for the whole system at once, which again, greatly limits the usefulness of disabling overcommit.
I know about mmap and mlock. Can you be more specific as to how they are useful in the scenario I mentioned above?
Specifically, when memory overcommit is disabled, I can use mmap() to allocate address space but this causes Linux to unnecessarily reserve swap space for the entire amount of the address space allocation.
This means that if the address space allocation is big enough, it would almost certainly fail even though I would only need to use a very tiny fraction of it.
Do you understand what I mean? Just because I allocate address space, it doesn't mean I will use all of it.
As far as I know, Linux can't handle this problem, because there's no way to communicate to the kernel which chunks of the address space allocation I wish to use.
Which means that disabling overcommit in Linux can be completely useless, because many mmap() calls start failing unnecessarily.
I don't think mlock() has anything to do with this problem.
When disabling overcommit, what you'd need to tell Linux is actually quite different: it's that you are about to start to use a new address range, so please make sure that there is enough free swap space for this address range (and reserve it!).
Only after the latter is completed would the kernel be allowed to allocate new pages for this range and the program would be allowed to use them. The kernel would also be free to swap them out to disk like normal, unless mlock() would be called (but only after those pages are already being used, not before!).
So as you can see, mlock() accomplishes something very different and is orthogonal to the functionality I'm discussing, which means it can be used (or not) independently of this new feature to reserve swap space.
This new functionality (to notify Linux that you are about to use a new address range) would also implicitly allow Linux not to reserve swap space for any address range for which it hasn't been notified, which would allow Linux to use swap space much more efficiently and would allow users to disable memory overcommit on Linux without causing a bunch of unnecessary program failures / crashes.
mmap(), on the other hand, normally does two things:
1. It allocates a range of address space.
2. It reserves swap space for this address range (when memory overcommit is disabled).
Notably (and people get confused by this a lot), mmap() doesn't actually allocate memory (i.e. memory pages), it only assigns a range of address space for the program to use, exactly as large as the program requested, and then reserves swap space for it, if required.
What I'm proposing is to separate those two things, i.e. allow programs to allocate address ranges separately from doing the swap space reservation.
If you don't separate these two things then programs allocating a huge range of address space will simply fail due to lack of available swap space (again, when memory overcommit is disabled, which is the goal here).
Just because a process allocates a certain amount of address space doesn't mean it will use all of it.
> The process requested a certain amount of memory to be allocated so surely it expects to use it, no?
No, not really. I think you are confusing memory usage with address space allocation.
You may wish to allocate a huge amount of address space for convenience purposes, as it could allow you to use much simpler data structures (such as sparse arrays) which can be a lot more performant than more complicated data structures and use a lot less memory (by orders of magnitude) than the address space that you allocated for them.
An example of this is AddressSanitizer's shadow memory, which is sort of a giant sparse bitmap whose address space is allocated up front, but only a small part of it is actually used at any one time.
From the blog post, it sounds like Windows has a separate system call that is required to be used in-between allocating address space and actually using it. I think this is a good design and I personally prefer it over Linux's overcommit design.
However, I think it has a disadvantage in that it could require you to do a lot more system calls (and therefore have slower performance) than would otherwise be needed in Linux, presumably (especially if the access patterns are unpredictable in advance?).
Also, if some process misbehaves and starts using more memory than there actually exists in the system, it can cause significant problems in other processes/applications that have nothing to do with it (as their allocations would start failing). Linux handles this by killing the misbehaving process, which allows the system to recover transparently / without intervention (at the risk of possibly killing innocent processes before actually killing the misbehaving one), hopefully allowing other processes to continue working as if nothing happened.
I think a reasonable approach could be to use Windows' system by default and guarantee that processes are never killed by the OS (which would benefit well-designed applications), but allow an application to optionally use overcommit if it wants the added performance (at the risk of being killed by the OOM killer if the system runs out of memory).
Unfortunately, I suspect that applications which actually handle out-of-memory conditions gracefully are very rare and that most of them would just crash or kill themselves if this happens, which on average is probably a worse outcome than letting the OS kill the misbehaving application.
Windows does allow you to reserve address space without committing it, but it then requires you to commit the chunks before you use them (see VirtualAlloc + MEM_RESERVE)
Personally, I think this is the right approach.
Because you shouldn't have to decide between memory overcommit (which can fail badly in some reasonable scenarios) or "having to reserve all allocated address space of all processes in swap", which is way too pessimistic and would start causing unnecessary memory allocation failures in many reasonable scenarios.
And I also think that even if you decide to support memory overcommit, it should be done per-process (at least), not at the whole system level like Linux is doing.
Indeed.
> From the blog post, it sounds like Windows has a separate system call that is required to be used in-between allocating address space and actually using it.
Precisely. You can reserve pages in the address space[1] without committing physical memory to back those pages. You can then later commit pages[2] when you want to use parts of that address space, or decommit[3] pages when you're done using them, without changing the reserved address space.
Coming from a Windows background I much prefer this system. I understand why Linux, with its reliance on forking, has gone with the overcommit route, but I consider it a sub-par solution. At least for non-server systems.
[1]: https://learn.microsoft.com/en-us/windows/win32/memory/virtu...
[2]: https://learn.microsoft.com/en-us/windows/win32/api/memoryap...
[3]: https://learn.microsoft.com/en-us/windows/win32/api/memoryap...
I come from a Linux background and I much prefer that system too.
Well, at least in theory, because in practice I don't usually run into these kinds of problems nowadays due to my hardware having significantly more memory than my software needs to run. But I still think Windows is designed more elegantly in that respect.
> I understand why Linux, with its reliance on forking, has gone with the overcommit route, but I consider it a sub-par solution.
Well, if Linux actually supported committing pages like Windows does, then there would be significantly less need for Linux to overcommit memory, because when forking you'd only have to reserve swap space for the committed memory of the process.
This means Linux wouldn't have to choose between reserving no swap space or reserving swap space for the entire address space (or some constant fraction of it, which Linux supports but doesn't make much sense either)!
This is one of those many instances where Windows is doing absolutely the right thing and it's Linux that's screwed up.
Microsoft put out an interesting PDF paper about fork():
https://www.microsoft.com/en-us/research/uploads/prod/2019/0...
I do not use Windows myself, but this is one thing I think they got right.
Then why does Solaris support fork() yet it doesn't do overcommit nor have an OOM killer? And also has a long history of being a very robust OS.
For more details, see my comment here: https://news.ycombinator.com/item?id=33708633
fork() + no overcommit + no OOM killer can work if you're very careful with allocations in processes that fork, but it would be a disaster on Linux. Willingness to put up with the drawbacks of Solaris is a good signal that you value robustness/stability very highly. IMO, most people developing for Linux have different priorities.
I don't quite like the overcommit approach nor the "all address space must be reserved in swap" approach, because both can fail badly in some reasonable scenarios.
I think having a separate system call to commit/uncommit memory like Windows seems to have is probably a better approach than just having mmap()/munmap() system calls (without a way of communicating with the kernel about which parts of the allocated space you are using), because then you can have the advantages of sparse address space usage while not having the drawbacks of having the OS kill innocent processes.
This would also have the advantage that in fork(), the kernel would just need to reserve swap space for the amount of committed memory, not the amount of allocated address space, the latter of which could be much larger (by orders of magnitude).
It turns out it probably works well/better in many cases, because apps don't actually use all the memory they request (up front), and for other reasons, but it's not the obvious choice to make. I would intuitively expect my OS to fail malloc if it does not have any enough memory available if I didn't know better.
I would expect an OS capable of expending its swap file to try doing it before failing my malloc call though.
It takes A LOT of time to expand the swap file. So failing malloc immeditately seems, to me, the right way to handle it.
Maybe adding an optional callback to malloc to be notified when further allocations are possible would be a better way to handle this.
Maybe it'd be possible to check if expanding the swap file is possible, return and then actually expand the swap file when convenient.
(I like being an armchair kernel developer :-))
In the rare case where a program wants to handle a failed allocation differently, then they should use a native system call that provides a more detailed interface than standard malloc. It doesn't matter if it's not portable since this is really a Windows-only thing.
Crashing is not good for anyone. A temporary freeze sucks, sure, but that's what you get for not having enough memory.
...plus, it's not like random freezing is a foreign concept to Windows users.
https://unix.stackexchange.com/questions/282155/what-is-the-...
Without over-committing, you could be preventing something that would work anyway. With it, the OOM could (often does) pick the biggest process that could very be using its memory legitimately AND be the most important process of this machine too.
But once you know about over-commit there are workarounds in languages where you control memory allocation, like touching every page right after you allocate it, but before using it. And in a garbage collected language you don't have any control or insight into when OOM exceptions will occur in either approach. So the ability for the OS to not trust lazy and greedy software that asks for memory but doesn't use it seems like a reasonable trade-off.
(Modulo vfork() and spawn() of course which are different and arguably better solutions to this issue.)
If you're over-committing memory then you don't find out your program ran out of memory until you try to access memory you've previously "allocated". If you're not over-committing, then you'll find out your program ran out of memory on an allocation where you might be better prepared to handle it.
Work is being done these days to improve the situation on Linux, but the default experience can be pretty painful. I was using Android Studio on a Fedora machine with on 8Gb of RAM, and sometimes the whole system would completely freeze for 10s of seconds at a time. This is not fun.
Some references to work on Linux: https://lwn.net/Articles/317814/ https://fedoraproject.org/wiki/Changes/EnableEarlyoom
I'll take the linux behavior any time when dealing with poorly written software (which is most software).
The Unix approach is better from a "realistic" point of view: most processes have a lot of library code they don't control and don't have time to audit. Usage patterns vary. And most processes end up reserving more memory than they ever actually touch. Note what they mentioned in the article - 3rd party graphics drivers run code in every process on Windows and that code allocates whatever it wants that counts against your commit limit. That isn't under your control at all and worse most of the time the memory is never touched.
Having lived under both systems I think I prefer the Unix view. In practice almost no Windows software does anything useful with commit limits so it just creates extra complexity and failure modes for little benefit.
I find this assertion dubious. Explicitly pre-allocating large arenas is common when micro-optimizing, which isn't something that happens for most apps out there - they just do the usual malloc/free (or equivalent) dance as needed. So for your average app, it boils down to the quality of implementation of its heap allocator. And there aren't that many of them to get right.
The general problem used to feature some sort of bug where some window processes would completely fail to render/paint UI components - instead, rendering them as pure black. The rendering problem is gone, same with a correlated memory leak, but the complete performance slowdown that accompanied it is still there.
One day I'll submit a bug report or profiler trace or something, but I find it odd every time I see a post about stability or performance fix, it never happens to be the big one that I run into, regardless of the window device or extensions.
It makes me wonder if some users just have browsing habits that most others don't, so they hit obscure bugs more frequently. But since everyone has their own obscure habits, and thus bugs, there's a theoretical endless deluge of problems with no critical mass to justify prioritization or investigation.
That said, I'll poke around in there next time anyways and see if anything stands out. Thanks!
On my computer, Firefox running out of memory is its own damn fault. Retrying memory allocation won't fix anything! And running out of commit space crashes everything else too, so Firefox letting itself crash isn't going to help, because it still brings down half the system. (And it still, already crashes when it runs out of memory.)
However, the type of solution you’re talking about would apply well to a caching server, and Varnish (on FreeBSD I believe) uses it quite successfully.
I've set a maximum swap size per partition, and you are suggesting to bypass it by falsely declaring your swap as cache?
Who died and made you NT_AUTHORITY\SYSTEM?
memory management is hard, and all major OSes still have serious problems with it.
I almost never had Firefox crash for more than a decade of heavy usage, then starting roughly 2 years ago it got janky quite often. Something changed.
I suppose it could be something particular to my setup but it is very slow in comparison to 'ungoogled-chromium' which I keep around as a second browser.
On the network tab I routinely find Firefox in a 'blocked' state for 100ms. On chrome this rarely exceeds 1ms. I've tried messing around with various configuration options and haven't found an answer. The end result is Chrome feeling much snappier.
I think a safe number for the modern web is like 64 Gb. At least if you want to have anything productive open besides the browser...
Of that Firefox that can fill 16 Gb zram with lz4 compression and all remaining physical RAM with less than 100 tabs loaded?
IMHO people using so many tabs seems to suggest a shortcoming somewhere else.
Tabs are really starting to bug me, i've tried a few tree tab managers and the ones i tried just don't work. I don't have a better solution. multiple windows is potentially bad news, as a crash may lose tabs you had open, even with a tab session manager. That is if you load several tabs in a new window and the computer or firefox crashes / reboots, you could lose history, cookies, possibly your old window layouts, etc. Tab session managers help a bit, by keeping consistently open tabs saved somewhere, but it doesn't help with new tabs and new windows if there's a crash.
Also it kinda solves the new window problem, as long as the new window is set to one of the tab groups (closing the window doesn't delete the tab group).
Also afaik when firefox crashes and is set to recover tabs, it should recover all the windows as well as the tabs.
And then a couple times a day I’ll open a bunch of threads in HN to read over the next few hours between other things.
Anything researching for a hobby can reach 10 tabs easily, though that usually happens “at home” so replaces rather than supplements the work tab count. And now we’re already at a few dozen tabs.
Having three monitors and other apps running you can “lose” a window and thus end up with the same site open in two or three windows. 50 tabs is usually about when I start garbage collecting, and I always manage to close something I still needed.
Look at them open few more and it's already easy to land on 10-20 tabs. Add some stuff always open (chats, webmail etc) and it's easy to get into 30s
I start every day with zero tabs but getting to 40-50 (then mass-closing if I found solution) is common. Vertical tabs addon is necessity (hell it's even nice with just 10 tabs)
At home I have several projects, I use TST (tree-style tabs), each project has a subtree. Sometimes I'll close off a tree, sometimes I'll save a tree to bookmark. An example tree was where I was investigating a problem with pdf files across some public resources (related to work), I had the principle sources for the PDFs, the PDFs themselves open, 6 tabs, then some searches looking for bug reports and each of those having child tabs of actual reports, then reference material raised through the bug report pages (gs and convert documentation). We're at about 20 tabs now -- meanwhile my console has at least 4 tabs open with gs and convert commands and man pages, I upload finding to gitlab (for reference when I'm at work) -- gitlab pages added to tab count. I test some pdf conversion commands, open a file manager (with its own tabs!) and open the results in the browser too. Midway one of the kids asks me about buying something, I switch to my Amazon tree of tabs, open a couple of searches and my basket, stack up some comparison prices in other tabs; one shop has several options where Amazon only has the one so I open them all and control-tab to do visual comparison; roughly +30 tabs, but I close off the tab trees that are poor prices or out-of-stock, down to about 10 tabs left until I make the actual purchase in ~10 days time.
I have a couple of hundred tabs open sometimes.
I don't find anything wrong with such a workflow.
> But the URL is gone when a tab is closed.
Accidentally closed tabs can be easily restored for as long as you don't delete the history. And when I reinstall a system I just restore the profile directory from the backup and Firefox will start with all plugins, settings and tabs from before.
For every subtopic, I open a few tabs, then browse them, compare them, reorder them, then close them. This is a recursive operation, hence why TreeTabs works well, esp. with the abimity to collapse.
If a new topic comes up, I'll open a new tab. I often leave tabs for if I have time to go back to them later, and that's where my thousands of tabs come from :/
Ideally I'd like to represent my tabs (and other OS windows, why not?) as a mind map. Open and close some topics. Export the topic to my bookmarks, share it... pearltrees come close.
... but every opinion piece that would fit in 1.5 kb of plain text loads 250 Mb of javascript ...
People like me that just want to web surf can disable JS by default and then single process mode -JS is infinitely more secure than a multi-process +JS. Just different use cases.
It's not like this hasn't been possible to do for many decades already.
I'm guessing the answer is something along the lines of "it makes applications freeze for <amount of time> and users don't like that".
Bu yes, the problem is probably not totally simple. adding delay in malloc while application might expect an immediate return could cause bugs. But swapping is a thing anyway and introduces delays so I don't know why they would not do this.
Also the tragedy of the commons, if everybody does this we are back to square one.
The actual solution is for the user to buy more memory, use a different app or change the workflow.
Also Windows should step in and say that this application is consuming almos all of the remaining memory, close others, or this or buy more RAM.
This is much more complicated that it appears, because the user could be intentionally doing that - if you have little memory (8 GB), you are sort of always almost out of it, if you have a lot but you are using professional apps like Photoshop, video editing, or doing machine learning with large datasets.
I'm sure that the reason Windows doesn't do this is because they couldn't figure out a good way to warn which is also not annoying.
There are some Windows warnings, I've seen them, but they only appear when the situation is so dire the computer is about to blue screen.
A marvelous operating system.
But yeah, at least I saw the warning fast, with the swap file it first came to a sudden halt, and after a lot of time it might have shown the alert.
I don’t see how you can realistically operate a computer this way unless you control all the software on it, or you enjoy buying way more RAM than you need.
(Also swap isn’t the only alternative to allocating memory - there’s also purgeable allocations and memory compression.)
To expend on your summary, this trick is necessary on Windows (only), because it does not allow over-committing and also does not have an OOM killer which you can instruct to kill content processes instead of the main process.
Now, its not even the same people that are involved in this issue and this article. So no, its not "the same folks".
Anyway, if it's the worst thing you have to complain about Mozilla, we are good I think. People really have weird battles to fight.
Right. After about 15 years, they finally relented. So, your position is, "it's not a problem, but they deserve credit for fixing that problem that shouldn't have been fixed"?
>Anyway, if it's the worst thing you have to complain about Mozilla, we are good I think.
Where are you getting that? When Mozilla did something stupid, I pointed to a related, similar stupid decision, originating from the same cultural practices. From that, you twist my words into meaning that's the only thing there is to criticize? That's the mind of an ideologue, not an honest evaluation for truth.
But, if you want to stay in the mentality of automatically trivialzing every unforced error on the part of Mozilla, then, by all means, apply that same reflexive defense to these cases as well!
- Looking Glass: Forcing a cryptic extension on users that accustoms them to ignoring changes that look like software compromise.[3]
- The fact that, post-2016-update, we still don't have the same add-on functionality as before, including the ability to customize controls.
- Not allowing side-loading of unsigned add-ons "because security" even though Chome has long allowed this with no issue.
- Then neglecting to keep the signing key up-to-date. [1]
- Then making previously-signed add-ons stop working as a result of that, compromising user privacy, possibly causing users in hostile countries to be killed. [1]
- Then assuring users that, no, it's okay because we can remotely force updates via an opt-out feature buried in "studies".[2]
All of those are worse, so no, the shitty, confusing in-joke at the expense of frustrated bug victims isn't actually the worst part about Mozilla, it's just the most relevant to the OP's comment. But sure, it provides a convenient way for you to imply that nothing else is wrong with Firefox.
>People really have weird battles to fight.
I'm sorry, what? Wanting a universal, everyday-utility software product to be accessible outside of a small clique ... is a weird battle to fight? That mentality is exactly Mozilla's problem!
[1] https://news.ycombinator.com/item?id=19823701
I didn't say this. At all. My position is "this minor issue is fixed now and does not really deserve any attention whatsoever anymore, didn't much at the time neither [, let's move on to actual problems]". I'm not saying Mozilla is perfect and don't have flaws. They have many. Some of which you have listed. And including their main source of cash. But this "Zaroo bogs found" thing? I appreciate that you don't agree with me, but sorry, it seems so irrelevant! By the way, how many regular, non-technical users face Bugzilla? None that I know of, and I'm surrounded by Firefox users. Most users don't write bug reports. And Firefox's bug reporting system is rather nice anyway, compared to other systems. It's localized, clear to follow, etc.
> post-2016-update, we still don't have the same add-on functionality as before
For the better and the worse, we are never getting this back. I hope you are not holding your breath over it. It's not happening. There are good maintainability and security reasons for this. We have the right to not agree with this but we are not the ones who maintain the browser. I work for a company that allows its software to be highly user customizable, it's our strength but that's not free and it comes with its own issues. We are stuck with old tech forever and cannot move very fast. I personally believe the restrictions are for the best.
> Wanting a universal, everyday-utility software product to be accessible outside of a small clique ... is a weird battle to fight
I didn't say this. I want this too. But Firefox is definitely already accessible outside of a small clique.
> From that, you twist my words into meaning that's the only thing there is to criticize?
I didn't say this. I said "IF". My sloppy phrasing really meant "that does not seem a big deal, of all the issues you could have found around Firefox and Mozilla".
> That mentality is exactly Mozilla's problem!
First, I have nothing to do with Mozilla, and second, I believe Mozilla is actually successful at providing software everyone can use.
A) You don't see any connection between "funny" and "in-joke",
B) You don't see any connection between "hip" and "showing affiliation with a high-status group".
Anyway, everything fully worked as intended for me: I had some fun reading this title, expected something interesting coming from hacks.mozilla.org and got it.
It's only clickbait if you claim that you have never seen it before. Do you wish to try to claim that?
The title is exactly the same both with and without the trailing extra few words, except one is dry and one attempts to be humorous.
You may for some reason find the attempted humor intolerable, but that's more about you than the article.
There is actually still a clickbaity element, but it's not anything you complained about, it's leaving out a few words to say "on Windows by avoiding overcommittting memory" or similar. Beginning a sentence and withholding the gist so the only way to know the end is to read the article, is indeed click bait.
Someday it will be possible to effectively filter all info that is presented on my devices, and along with anyone/anything mentioning Trump and Musk, overly-clever articles that sound like clickbait will be gone along with the real thing.
Only when it's used ironically. If the article uses that as a headline and forces you to read the whole thing before giving so much as a hint what the "one weird trick" is, then it's legitimate clickbait.
Don't get me wrong, it's an interesting article. I just think if an article is attempting to humorously use a clickbait headline, then it owes it to the reader to at least add a subheading.
More specifically - on the memory front - we spent lots of engineer/years working on improvements which sometimes would barely register, only for some weird trick make OOM crashes fall off the radar entirely.
Also I'd like to point out that we have no way to tell if this is working because we give Windows time to resize the swap file, if it's because other processes in Firefox die, or it's because other unrelated processes die, or a mix of all the above. It's pure speculation on our part.
I expect followup by some annoyed blogger that notices swap file ate his system partition and he spent whole day debugging the reason of that...
This doesn’t work the way adopting kids’ slang “ruins” it and gets them to stop using it. Nobody doing it is worried about looking cool.
Sure, it could also just be "Improving Firefox stability", but that doesn't tell me the nature or scale of the update.