[LoganDark]

Holy crap, this is the most helpful answer I've ever seen from a Firefox developer on HN. When I was having a memory exhaustion issue, I was just told "enable the page file, running without overcommit is a recipe for disaster" (looks at my 40GB of memory). I should figure out if that issue still occurs.

[mort96]

Running without overcommit is a recipe for disaster! Modern JITs make good use of virtual memory for both security and performance reasons.

Firefox on my laptop currently consumes almost 400GiB of virtual address space, while consuming "only" 458GiB of RSS. And that's not a bug, that's simply the browser making good use of the virtual memory system to provide significant advantages to all users on systems without overcommit disabled (which I'm guessing is 99.99% of people).

The difference in response you're seeing is simply because ta1243 is reporting a Firefox bug and you're reporting user error.

EDIT: Here's some further reading on some of the ways which Chrome's JavaScript engine (V8) uses virtual memory for security: https://docs.google.com/document/d/1HSap8-J3HcrZvT7-5NsbYWcj...

[LoganDark]

> simply because ta1243 is reporting a Firefox bug and you're reporting user error

Don't tell me Firefox needs 40GB of virtual memory to keep a tab open for longer than a couple weeks. Or that it's the JavaScript engine when closing all tabs or windows didn't free the memory, only restarting the entire browser did. It wasn't the extensions, either.

If Chromium works properly without leaking memory, and Firefox leaks memory and calls it "user error" to not have overcommit enabled, I'm going to use Chromium, simply because it actually respects my computer's resources.

Also, you're citing ways in which Chromium's V8 uses virtual memory, when V8 does not suffer from this problem. Clearly you can use virtual memory in that way without having a memory leak.

Also remember that Windows does not have unlimited overcommit like Linux does, because it has no OOM killer. So if Firefox were to use 400GiB of virtual memory, that would require the page file to take up the remainder of that.

I did have issues with my page file "automatically" growing to 64GiB with Firefox running, so maybe it literally does do this and it actually uses up hundreds of gigabytes of space on Windows machines. But that is not acceptable behavior from Firefox and it is definitely not user error to not want to give up that much space.

[jraph]

> running without overcommit is a recipe for disaster

(but yes, it probably is, even with 40GB of memory. I bet many things are designed on Linux with overcommit as an assumption)

[ta1243]

My laptop has a mere 32G of ram and 6G swap (currently unused but I did reboot last week)

The advice used to be 1.5*physical ram for swap back in the days when I had 4MB of ram and 170MB HDD - well under 5% of disk space Doing that today would be 20% of my disk space which seemed excessive.

Perhaps I could create a 24G swap file as a ram drive, giving me 8G of ram and 24G of swap. Why would that be better than just 32G of ram and no swap? Is it better than 40G of ram and no swap?

[jraph]

> 1.5*physical

Yep. This was a rule of thumb which I don't think still holds with current RAM capacities.

I don't have swap on my 32G laptop, not sure it's right I guess I could use a 2G-4G swap partition when running a few XWiki instances and a Java IDE as well as a browser with several dozens of tabs instead of having the IDE frequently OOM-killed.

[ddalex]

I stopped worrying about swap when I learned how to use zram.

[LoganDark]

Well, that was just the wrong answer, since their software is supposed to be releasing memory back to the OS properly. Overcommit is just a coping mechanism, you should be addressing the root cause.

I have since enabled the page file for other reasons - LLMs demand up to 50GB of memory sometimes, and my new desktop only has 16.

The change of machine is why I should probably try Firefox again to see if it behaves.

[ColonelPhantom]

Overcommit != Swap.

Overcommit is allocating virtual memory without any backing. Swap is allocating physical memory backed by disk.

Overcommit is useful in some cases, for example to preallocate a large heap without immediately making it all resident. Or to allocate 'guard' pages to fight buffer overflows. On Linux, overcommit is commonly assumed and as such disabling it tends to break some programs, as it's not out of the ordinary for something to allocate 100s of GBs of virtual memory.

[LoganDark]

Read up on Windows. Windows does not do overcommit whatsoever, unless swap is enabled, in which case it only allows overcommit up to the size of the swap file.

Overcommit cannot be enabled without a swap file, whatsoever. This differs from Linux that can tend to have overcommit enabled without swap.

[ColonelPhantom]

Yes, Windows doesn't have overcommit. (Also not with swap, since overcommit is unbacked virtual memory, which Windows still doesn't allow. The only thing it allows is disk-backed virtual memory).

But as a user, I don't care (except that I don't have to worry about an OOM killer because an allocation will just fail). The only real difference is that application developers need to be careful with allocating memory without using it, unlike on Unix-likes.

Because software on Linux runs on the assumption of overcommit, you shouldn't disable it, even though the lack of overcommit on Windows is not problematic.

[fomine3]

You're correct, that's why having pagefile is important for Windows even if there's enough RAM. Why don't you enable it?

[LoganDark]

It takes up disk space that I thought I could save. I have it enabled now, as a side effect of working with LLMs on my new computer that only has 16GB of memory (working on fixing that).

I still wouldn't be comfy letting Firefox fill it up, because no matter how large the page file is, your system will always crash when Firefox fills the entire thing. I do not know if my new computer will have this problem, though.

[mort96]

The reasons browsers rely on overcommit has nothing to do with them failing to release memory back to the OS properly.

[LoganDark]

If the memory is never released back to the OS after it is done being used (or when it is not going to be used), then the browser has failed to release it back to the OS.

[mort96]

The memory is released back to the OS after it is done being used.

[LoganDark]

If that were the case my OS would not crash due to tens of gigabytes of allocated-but-not-used memory from Firefox