https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115031
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
Uni-Bielefeld.DE> ---
I've done some digging now, comparing mmap calls on Solaris/i386 and
Solaris/SPARC (counts and sizes each):
i386:
2 4096
7 8192
5 16384
7 32768
4 65536
3 131072
2 262144
3 524288
2 1048576
1 1662976
892 2097152
2 3313664
1 4194304
total ca. 1784 MB
getconf PAGE_SIZE -> 4096
sparc:
491 8192
6 16384
4 32768
3 65536
2 131072
1 262144
2 524288
1 1048576
1 2097152
986 4194304
total ca. 3947 MB
getconf PAGE_SIZE -> 8192
In a next step, I disabled MAPPED_{READING, WRITING} in
gcc/cp/module.cc, but that made almost no different on i386 and didn't
cure the allocation failure on sparc.
Looking closer at the mmap64 call chains, they are primarily from
ggc_internal_alloc. So I undef'ed USING_MMAP there, with astonishing
results for runtimes:
* i386 with mmap in module.cc and ggc-page.cc:
real 30.12
user 29.62
sys 0.14
* i386 with fileio in module.cc and mmap in ggc-page:
real 29.93
user 29.50
sys 0.21
* i386 with fileio in module.cc and USING_MMAP undef'ed in ggc-page.cc:
real 28.53
user 28.19
sys 0.16
* sparc with the same combination allows the test to run to complition
for the first time:
real 37.81
user 37.46
sys 0.14
I wonder what to make of that beyond the failing sparc testcase.
