On 09/04/17 21:06, Markus Trippelsdorf wrote: > On 2017.04.09 at 21:10 +0200, Markus Trippelsdorf wrote: >> On 2017.04.09 at 21:25 +0300, Alexander Monakov wrote: >>> On Sun, 9 Apr 2017, Markus Trippelsdorf wrote: >>> >>>> The minimum size heuristic for the garbage collector's heap, before it >>>> starts collecting, was last updated over ten years ago. >>>> It currently has a hard upper limit of 128MB. >>>> This is too low for current machines where 8GB of RAM is normal. >>>> So, it seems to me, a new upper bound of 1GB would be appropriate. >>> >>> While amount of available RAM has grown, so has the number of available CPU >>> cores (counteracting RAM growth for parallel builds). Building under a >>> virtualized environment with less-than-host RAM got also more common I >>> think. >>> >>> Bumping it all the way up to 1GB seems excessive, how did you arrive at that >>> figure? E.g. my recollection from watching a Firefox build is that most of >>> compiler instances need under 0.5GB (RSS). >> >> 1GB was just a number I've picked to get the discussion going. >> And you are right, 512MB looks like a good compromise. >> >>>> Compile times of large C++ projects improve by over 10% due to this >>>> change. >>> >>> Can you explain a bit more, what projects you've tested?.. 10+% looks >>> surprisingly high to me. >> >> I've checked LLVM build times on ppc64le and X86_64. > > Here are the ppc64le numbers (llvm+clang+lld Release build): > > --param ggc-min-heapsize=131072 : > ninja -j60 15951.08s user 256.68s system 5448% cpu 4:57.46 total > > --param ggc-min-heapsize=524288 : > ninja -j60 14192.62s user 253.14s system 5527% cpu 4:21.34 total >
I think that's still too high. We regularly see quad-core boards with 1G of ram, or octa-core with 2G. ie 256k/core. So even that would probably be touch and go after you've accounted for system memory and other processes on the machine. Plus, for big systems it's nice to have beefy ram disks as scratch areas, it can save a lot of disk IO. What are the numbers with 256M? R.
