This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Patch: RAM-based heuristics for ggc-min-heapsize and ggc-min-expand
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>, Richard dot Earnshaw at arm dot com, gcc-patches at gcc dot gnu dot org, geoffk at geoffk dot org, mstump at apple dot com
- Date: Sat, 15 Feb 2003 15:28:05 +0000
- Subject: Re: [RFC] Patch: RAM-based heuristics for ggc-min-heapsize and ggc-min-expand
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
>
> > > From: Zack Weinberg <zack@codesourcery.com>
> > >
> > > We should take rlimits into account in the heuristics.
> > > zw
> >
> > How? Which one?
>
> RLIMIT_RSS is the obvious one - that's the limit on resident set size,
> i.e. the OS will start paging us if we exceed it. I'd suggest taking
> the minimum of that and the actual physical memory size as the input
> to the heuristic.
RLIMIT_RSS would certainly be better than physical memory if it is lower.
Consider that we have x86 machines with 8G of RAM, though clearly a single
process can't access more than 4G (and probably less, since the OS has to
be mapped in somewhere).
>
> It doesn't make sense for us to try to consider RLIMIT_DATA etc, since
> we don't have enough control to guarantee that we don't go over those.
>
RLIMIT_DATA would be completely wrong anyway. That's the maximum virtual
data size (including swapped out data). If the compiler exceeds that then
it's just going to get killed by the OS.
R.