Memory use compiling 28.10.0

[digitalaudiorock]

I use palemoon under Gentoo and have been able to compile it without issue using gcc 9.2 up to version 28.8.2.1. This is on an older machine with only 2 GB of RAM. Version 28.10.0 fails with a memory allocation error, so apparently something in 28.10.0 uses way more RAM than did the older versions.

Does anyone have any suggestions as to how I might be able to work around that? Unfortunately I'm not able to add any RAM to this system. I tried setting the gentoo MAKEOPTS to -j1 rather than my usual -j2 but it still failed.

Thanks!
Tom

[athenian200]

I use palemoon under Gentoo and have been able to compile it without issue using gcc 9.2 up to version 28.8.2.1. This is on an older machine with only 2 GB of RAM. Version 28.10.0 fails with a memory allocation error, so apparently something in 28.10.0 uses way more RAM than did the older versions.

Does anyone have any suggestions as to how I might be able to work around that? Unfortunately I'm not able to add any RAM to this system. I tried setting the gentoo MAKEOPTS to -j1 rather than my usual -j2 but it still failed.

Thanks!
Tom

You really can't compile the browser yourself on a system with only 2GB reliably. I think 8GB is basically the minimum we'd recommend.

That being said, we are doing something called "deunifying the tree," that is likely what's causing use of RAM to go up significantly, and especially during the linking stage. That said, if you really want to try and do it in 2GB, you might try using an older version of GCC and turn off optimization with -O0 or something. The oldest compiler we test with is GCC 4.9. Also, are you doing a 32-bit build or a 64-bit build? 32-bit build would take up less RAM, and there's no advantage to a 64-bit build on a system with less than 4GB of RAM. You should also be using a 32-bit version of GCC itself to minimize RAM use. Well, to be honest, with only 2GB of RAM available, you should be using a 32-bit version of Linux period.

Another way I've used personally is using distcc to do part of the compilation on another computer. If you have another machine available, you can use distcc and distribute part of the build to it. The linking will still be done on the machine you run it from, though, which may be a problem when it comes time to link libxul.so.

[The Squash]

Oh. I guess you haven't read that article about the latest innovation in computer technology...

BREAKING NEWS: SWAP HAS BEEN INVENTED
December 25th, 1991

(Ed -- I know that swap existed before Linux had support for it. Don't badger me about that, certain people around here.)

[The Squash]

[T]here's no advantage to a 64-bit build on a system with less than 4GB of RAM

Sorry athenian200, but you're wrong: There's a huge incentive to run a 64-bit OS even with less than 4GB of RAM.

I have a rare 64-bit machine with 1GB RAM, and I tell you gcc runs about three times as fast as in 32-bit mode. And this is using Gentoo.

Also 64-bit processors are usually designed to run 64-bit code, not 32-bit code. Even those old 64-bit chips.

Plus it's actually quite rare that 64-bit code is more than 15% larger than 32-bit code. I can prove that, if you want me to.

Finally, if digitalaudiorock adds swap to their system, gcc won't be able to take full advantage of all the swap if run in 32-bit mode -- only the 2GB of RAM plus 1GB swap, totalling up to 3GB.

So digitalaudiorock, please don't take athenian200's advice on that one. Please take my advice about adding a swap file or swap partition, if you don't already have one.

[Moonchild]

BREAKING NEWS: SWAP HAS BEEN INVENTED

And if you compile and link relying on swap, your resulting binary will likely be extremely unstable.

[New Tobin Paradigm]

Don't listen to The Squash, he literally doesn't know what he is talking about. One should have at least 6gb of ram to successfully compile but that assumes a light DE and nothing else really running. Otherwise, 8gb should give you enough wiggle room.

Do NOT allow the complilation nor linking especially linking libxul to swap. It will produce unstable binaries if not just fatal error outright.

Athenian200 is quite correct, and unlike The Squish, actually has experence working with the codebase even beyond JUST compiling. I would listen to him and not that vaporware know-nothing moron.

[stevenpusser]

It's a known issue with the last couple releases and 32-bit linking--just look at the thread for my OBS repo to see me having trouble with it and the solution to reduce memory overhead during linking.

tl;dr

use this in mozconfig:

Code: Select all

ac_add_options --enable-optimize="-O2 -w -Wl,--no-keep-memory,--reduce-memory-overhead"

Linking is a single process, and on 32-bit, a single process can't use more than 4 GB of memory, no matter how much extra memory you add via swap or with PAE.

[New Tobin Paradigm]

That certainly is another wrinkle, thanks for reminding us stevepusser.

Anyway, as one can see it isn't as simple as some would claim when it comes to a classical mozilla-style codebase. You have to be aware of many factors when you compile for yourself.

[athenian200]

Sorry athenian200, but you're wrong: There's a huge incentive to run a 64-bit OS even with less than 4GB of RAM.

I have a rare 64-bit machine with 1GB RAM, and I tell you gcc runs about three times as fast as in 32-bit mode. And this is using Gentoo.

Also 64-bit processors are usually designed to run 64-bit code, not 32-bit code. Even those old 64-bit chips.

Plus it's actually quite rare that 64-bit code is more than 15% larger than 32-bit code. I can prove that, if you want me to.

Finally, if digitalaudiorock adds swap to their system, gcc won't be able to take full advantage of all the swap if run in 32-bit mode -- only the 2GB of RAM plus 1GB swap, totalling up to 3GB.

So digitalaudiorock, please don't take athenian200's advice on that one. Please take my advice about adding a swap file or swap partition, if you don't already have one.

That isn't my experience. I've seen significant reductions in RAM use with 32-bit applications over 64-bit in memory-constrained environments. You think I'm wrong, and I think you're wrong, so I guess we're just going to have to agree to disagree on this one. My view is pretty conventional wisdom and it's well-known in IT circles. If you look into this yourself, you'll see there's not even an argument to be had.

Basically, pointers take up twice as much space in 64-bit as they do in 32-bit. If you look at the system requirements of applications that have 32-bit and 64-bit versions, you often see the recommended minimum RAM for the 64-bit version is doubled. Surely that's not just marketing, and they would love to sell a 64-bit version to someone with less RAM if it would run fine. A lot of people were upset that the Raspberry Pi 3 had a 64-bit processor but only 1GB of RAM for this very reason, because when they went to install a 64-bit OS, they found that everything took up more RAM and it was kinda useless.

Using swap really sucks unless you're swapping to an SSD or something (and when compiling it can be dangerous, as stated above), but on most computers with 2GB or less, you'll have a mechanical hard drive, so using swap isn't a good suggestion for that reason alone. The only use of swap on such a machine that makes sense is literally buying a USB stick and using it with Windows ReadyBoost, a feature Microsoft brought out in Vista because computers were too low on RAM to run it properly.

Anyway, OP, I would suggest listening to stevepusser in this particular case rather than either one of us. His recommendations directly relate to to the linking, mine were more general ways of reducing RAM use while compiling. We have one very big library that takes an enormous amount of RAM to link.

[The Squash]

I've seen significant reductions in RAM use with 32-bit applications over 64-bit in memory-constrained environments. You think I'm wrong, and I think you're wrong, so I guess we're just going to have to agree to disagree on this one. My view is pretty conventional wisdom and it's well-known in IT circles. If you look into this yourself, you'll see there's not even an argument to be had.

Let's see if that's true: I performed this following test on the official Pale Moon 28.10.0 32-bit and 64-bit versions. I don't care that they have different build parameters -- digitalaudiorock probably isn't going to use the official configuration anyway.

64-bit version:

Code: Select all

total 101364
-rw-r--r-- 1 gentoo gentoo      430 Jun  4 18:27 application.ini
drwxr-xr-x 7 gentoo gentoo      220 Jun  4 19:05 browser
-rw-r--r-- 1 gentoo gentoo        0 Jun  4 19:05 chrome.manifest
drwxr-xr-x 2 gentoo gentoo       60 Jun  4 19:05 components
drwxr-xr-x 3 gentoo gentoo       60 Jun  4 19:05 defaults
-rw-r--r-- 1 gentoo gentoo      127 Jun  4 19:05 dependentlibs.list
drwxr-xr-x 2 gentoo gentoo       80 Jun  4 19:05 dictionaries
drwxr-xr-x 2 gentoo gentoo       60 Jun  4 19:05 fonts
drwxr-xr-x 2 gentoo gentoo       60 Jun  4 19:05 icons
-rw-r--r-- 1 gentoo gentoo 11696784 Jun  3 07:44 icudt58l.dat
-rw-r--r-- 1 gentoo gentoo      899 Jun  4 19:05 libfreeblpriv3.chk
-rwxr-xr-x 1 gentoo gentoo   530968 Jun  4 19:05 libfreeblpriv3.so
-rwxr-xr-x 1 gentoo gentoo    59712 Jun  4 19:05 liblgpllibs.so
-rwxr-xr-x 1 gentoo gentoo  1834944 Jun  4 19:05 libmozavcodec.so
-rwxr-xr-x 1 gentoo gentoo   212488 Jun  4 19:05 libmozavutil.so
-rwxr-xr-x 1 gentoo gentoo   900688 Jun  4 19:05 libmozsqlite3.so
-rwxr-xr-x 1 gentoo gentoo   240472 Jun  4 19:05 libnspr4.so
-rwxr-xr-x 1 gentoo gentoo  1013384 Jun  4 19:05 libnss3.so
-rwxr-xr-x 1 gentoo gentoo   531888 Jun  4 19:05 libnssckbi.so
-rw-r--r-- 1 gentoo gentoo      899 Jun  4 19:05 libnssdbm3.chk
-rwxr-xr-x 1 gentoo gentoo   117760 Jun  4 19:05 libnssdbm3.so
-rwxr-xr-x 1 gentoo gentoo   175584 Jun  4 19:05 libnssutil3.so
-rwxr-xr-x 1 gentoo gentoo    18744 Jun  4 19:05 libplc4.so
-rwxr-xr-x 1 gentoo gentoo    14552 Jun  4 19:05 libplds4.so
-rwxr-xr-x 1 gentoo gentoo   139960 Jun  4 19:05 libsmime3.so
-rw-r--r-- 1 gentoo gentoo      899 Jun  4 19:05 libsoftokn3.chk
-rwxr-xr-x 1 gentoo gentoo   237736 Jun  4 19:05 libsoftokn3.so
-rwxr-xr-x 1 gentoo gentoo   312320 Jun  4 19:05 libssl3.so
-rwxr-xr-x 1 gentoo gentoo 76264744 Jun  4 19:05 libxul.so
-rw-r--r-- 1 gentoo gentoo  8773465 Jun  4 19:05 omni.ja
-rwxr-xr-x 1 gentoo gentoo   175120 Jun  4 19:05 palemoon
-rwxr-xr-x 1 gentoo gentoo   175120 Jun  4 19:05 palemoon-bin
-rw-r--r-- 1 gentoo gentoo       47 Jun  4 19:05 platform.ini
-rwxr-xr-x 1 gentoo gentoo   162736 Jun  4 19:05 plugin-container
-rw-r--r-- 1 gentoo gentoo     2031 Jun  4 19:05 precomplete
-rw-r--r-- 1 gentoo gentoo      707 Jun  4 19:05 removed-files
-rwxr-xr-x 1 gentoo gentoo     8915 Jun  3 07:44 run-mozilla.sh
-rwxr-xr-x 1 gentoo gentoo   120928 Jun  4 19:05 updater
-rw-r--r-- 1 gentoo gentoo      685 Jun  4 19:05 updater.ini
-rw-r--r-- 1 gentoo gentoo      136 Jun  4 19:05 update-settings.ini

32-bit version:

Code: Select all

total 105166
-rw-r--r-- 1 root root       57 Feb  7 19:40 active-update.xml
-rw-r--r-- 1 root root      429 Jan 27 20:35 application.ini
drwxr-xr-x 7 root root      218 Jan 27 20:54 browser
-rw-r--r-- 1 root root        0 Jan 27 20:54 chrome.manifest
drwxr-xr-x 3 root root       27 Jan 27 20:54 defaults
-rw-r--r-- 1 root root      127 Jan 27 20:54 dependentlibs.list
drwxr-xr-x 2 root root       49 Jan 27 20:54 dictionaries
drwxr-xr-x 2 root root       54 Jan 27 20:54 fonts
drwxr-xr-x 2 root root       34 Jan 27 20:54 icons
-rw-r--r-- 1 root root 11696784 Oct 24  2019 icudt58l.dat
-rw-r--r-- 1 root root      899 Jan 27 20:54 libfreeblpriv3.chk
-rw-r--r-- 1 root root   526844 Jan 27 20:54 libfreeblpriv3.so
-rw-r--r-- 1 root root    41432 Jan 27 20:54 liblgpllibs.so
-rw-r--r-- 1 root root   981588 Jan 27 20:54 libmozsqlite3.so
-rw-r--r-- 1 root root   255468 Jan 27 20:54 libnspr4.so
-rw-r--r-- 1 root root   935728 Jan 27 20:54 libnss3.so
-rw-r--r-- 1 root root   376692 Jan 27 20:54 libnssckbi.so
-rw-r--r-- 1 root root      899 Jan 27 20:54 libnssdbm3.chk
-rw-r--r-- 1 root root   115548 Jan 27 20:54 libnssdbm3.so
-rw-r--r-- 1 root root   142040 Jan 27 20:54 libnssutil3.so
-rw-r--r-- 1 root root    16580 Jan 27 20:54 libplc4.so
-rw-r--r-- 1 root root    10532 Jan 27 20:54 libplds4.so
-rw-r--r-- 1 root root   127124 Jan 27 20:54 libsmime3.so
-rw-r--r-- 1 root root      899 Jan 27 20:54 libsoftokn3.chk
-rw-r--r-- 1 root root   209736 Jan 27 20:54 libsoftokn3.so
-rw-r--r-- 1 root root   281396 Jan 27 20:54 libssl3.so
-rw-r--r-- 1 root root 82499784 Jun 26 22:29 libxul.so
-rw-r--r-- 1 root root  8937468 Jan 27 20:54 omni.ja
-rwxr-xr-x 1 root root   199256 Jan 27 20:54 palemoon
-rw-r--r-- 1 root root       47 Jan 27 20:54 platform.ini
-rw-r--r-- 1 root root   178612 Jan 27 20:54 plugin-container
-rw-r--r-- 1 root root     1895 Jan 27 20:54 precomplete
-rw-r--r-- 1 root root      707 Jan 27 20:54 removed-files
-rw-r--r-- 1 root root     8915 Apr 21  2019 run-mozilla.sh
-rw-r--r-- 1 root root   133540 Jan 27 20:54 updater
-rw-r--r-- 1 root root      685 Jan 27 20:54 updater.ini
drwxr-xr-x 3 root root       24 Feb  7 19:40 updates
-rw-r--r-- 1 root root      136 Jan 27 20:54 update-settings.ini
-rw-r--r-- 1 root root       57 Feb  7 14:05 updates.xml

Look at how 64-bit libxul.so is smaller than 32-bit libxul.so -- and many of the other 64-bit libraries and programs there are smaller than their 32-bit counterparts.

Anybody who has a bone to pick with me, just download a Pale Moon tarball.

[The Squash]

And if you compile and link relying on swap, your resulting binary will likely be extremely unstable.

Why is that? I've compiled Pale Moon dozens of times with swap and I've never encountered a build failure or quirky performance that wasn't present in the official build.

[New Tobin Paradigm]

Can we ban this person now?

[adesh]

Off-topic:
It's fine to agree/disagree. Let's not be too argumentative about it.

[New Tobin Paradigm]

There is nothing to disagree about. The risk is too great to rely on swapping during compiling and especially linking. Just because it works once or works on one specific setup does not mean it will be as successful (which I seriously question) on a different distro, hardware, gcc version, and the number of neutrinos passing through the processor at the time.

It is not reliable and must be discouraged.

Just don't do it or listen to freaks who contradict those who have been doing this for a long time.

[Moonchild]

Look at how 64-bit libxul.so is smaller than 32-bit libxul.so -- and many of the other 64-bit libraries and programs there are smaller than their 32-bit counterparts.

Anybody who has a bone to pick with me, just download a Pale Moon tarball.

Are you really that clueless about compilation? I guess you must be... which is surprising for someone using gentoo, actually.

What size the final .so has on Linux has no relation to how much memory is being used when building/linking.
In fact, that final size depends on many factors, also on differences in compiler instructions per architecture (and I'm not even sure if travis is using the same compiler version here for each architecture; he might not be!).

who contradict those who have been doing this for a long time.

We've been doing this for over 10 years. And regardless of O.S., regardless of compiler and regardless of linker, if swap is actively being used during the linking process, it will result in unstable binaries in most cases, which can vary from build to build. This affects MSVC/Win, gcc/Linux and clang/Mac alike. You can't beat practical experience here, Squash.

[gh_origin]

The guys is clearly wrong. Swap can't replace physical memory. If you lucky, it would compile and link successful, but it will take eons to complete the linking process. Of course you can't know this if you don't watch your screen regularly but let it do it job overnight! But in my own experience, it usually just hang there and finally failed or still stuck. 2G of ram is impossible to compile anything large at all.

[digitalaudiorock]

Wow, a lot of replies here. To be clear, I'd already tried increasing swap dramatically and that didn't help. I'll probably try stevepussers change and see if that helps at all.

Thanks for the suggestions!
Tom

EDIT: Yes I have heard of swap, and thanks Squash for the incredibly obnoxious insult to my intelligence. That was really called for.

[Isengrim]

One should have at least 6gb of ram to successfully compile but that assumes a light DE and nothing else really running. Otherwise, 8gb should give you enough wiggle room.

FWIW I'm able to compile Ambassador on a headless Ubuntu VM with 4 GB of RAM no problem. But that's on a dedicated VM with no DE at all.

[New Tobin Paradigm]

Yeah, it does depend on what is running and how many parallel processes also features to be built. Ambassador tends to have the least stuff with Borealis as a close second followed by Pale Moon with Interlink and Basilisk in a close race for most stuff built.

I would not try and compile Pale Moon or anything else without at least 5.5gbs free. 4 free seems reasonable depending on cores except for libxul linking which can peak close if not exceeding 5.

It really does depend on a lot and because of all those factors we have a recommendation with wiggle room because swaping is unpredictable and even if it works the potental instability can be subtle if not obvious. One build that swaps may be fine but another may cause your cpu to start a fusion reaction and melt down to the core of the planet ending in a chain reaction that will result in the destruction of Earth.

Just best to play it safe and if you want to try to take it down as far as you can it is a lot of trial and error (I know this because I have done exactly this). Also keep in mind as de-unifing sources progresses more ram will be required.

[stevenpusser]

There is another flag you can use in the mozconfig file to limit the threads used in compiling PM. I use it on the OBS builds since the ARM build platforms there don't have as much RAM available as the x86 ones. But a 2GB machine may not have multiple threads, anyway:

Code: Select all

# Builds use all available cores by default--enable and tune this option to
# reduce CPU use and memory consumption during builds. RAM use seems to be about 
# 0.75 GiB per thread. "-jX", where X=number of threads for the build. Example: 
mk_add_options MOZ_MAKE_FLAGS="-j4"