sysctl, HW_PHYSMEM, and crippled gcc

[Dan Nelson]

In the last episode (Dec 08), Steve Kargl said:
> Anyone have any insight into fixing gcc to make better use of system
> memory on systems with more than 4 GB. It appears that
> libiberty/physmem.c tries to use sysctl() to determine the amount of
> physical memory in a system.
> 
>   { /* This works on *bsd and darwin.  */
>     unsigned int physmem;
>     size_t len = sizeof physmem;
>     static int mib[2] = { CTL_HW, HW_PHYSMEM };
> 
>     if (sysctl (mib, ARRAY_SIZE (mib), &physmem, &len, NULL, 0) == 0
>         && len == sizeof (physmem))
>       return (double) physmem;
>   }
> 
> This works if you have less than 4GB because of the unsigned int
> physmem.  I have 12 GB, which of course, when expanded to the number
> of bytes doesn't fit into a unsigned int physmem.

physmem is actually an unsigned long, not an unsigned int, so on amd64
that sysctl call should fail anyway (amd64 is LP64, so a long won't fit
into an int).
 
> What is the ramification?  Well, gcc uses this estimate of
> memory to size internal parameters.
> 
> troutmask:sgk[259] gcc -v h.c
> Using built-in specs.
> Configured with: FreeBSD/amd64 system compiler
> Thread model: posix
> gcc version 3.4.4 [FreeBSD] 20050518
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> 
> In particular, ggc-min-heapsize=4096 is ridiculously small for a
> system with 12 GB of memory.

On all my FreeBSD boxes from 128MB to 1GB of RAM, I get the exact same
heuristic values as you, so I'm not sure whether the code works at all.
I seem to remember having the opposite problem on a memory-limited
machine which insisted in allocating a relatively huge percentage of
RAM for a sort, and gnu sort uses the same physmem() call for its
dynamic sizing.

-- 
	Dan Nelson
	dnelson at allantgroup.com