[Bug other/50636] New: GC in large LTO builds cause excessive fragmentation in memory map

["andi-gcc at firstfloor dot org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636

             Bug #: 50636
           Summary: GC in large LTO builds cause excessive fragmentation
                    in memory map
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: andi-gcc@firstfloor.org


When doing a very large LTO build I fail with "out of virtual memory"

Some investigation showed the problem was not actually running out of 
memory, but gcc excessively fragmenting its memory map. The Linux kernel
has a default limit of 64k mappings per process and the fragmentation 
exceeded that. This lead to gc mmap allocations failing and other problems.

A workaround is to increase /proc/sys/vm/max_map_count

Looking at /proc/$(pidof lto1)/maps I see there are lots of 1-3 page holes
between other anonymousmemory. I think that's caused by ggc-pages free_pages()
function freeing too early and in too small chunks
(and perhaps LTO garbage collecting too much?)