This is the mail archive of the
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: Mike Stump <mstump at apple dot com>
- Cc: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>, geoffk at geoffk dot org, Richard dot Earnshaw at arm dot com, gcc-patches at gcc dot gnu dot org
- Date: Fri, 14 Feb 2003 10:02:37 +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
> On Thursday, February 13, 2003, at 05:59 PM, Kaveh R. Ghazi wrote:
> > I think the idea is that you'd get the info as part of the standard
> > bug report -v invocation. I.e.
> > cc1 -fpreprocessed -O2 -g -blah -blah ... -param ggc-min-heapsize=x
> > and you would automatically pass it back when reproducing the bug. If
> > we simply output the numbers with a printf then we have to teach
> > people new bug reporting and reproducing instructions cause they'd
> > have to gleen out and manually add these -param commands.
> > Ok?
> I think the point is that be design, 99% of the time, it won't be
> necessary to know or have that information to reproduce a bug. We can
> put it in ggc-page (or where-ever) and if it really it a problem later,
> it is possible to move it up.
But when it is we get into the situation that we might not know that that
is the problem -- ie we run the testcase and find that it works, so the
bug report is summarily closed (not reproducable).
> Also, no, I disagree. The current instructions should encourage the
> submitter to submit the output of -v. If -v shows the information,
> then a bug reproducer/fixer can use that information, if they need it.
Putting it on the interface
1) Shows us what the values are.
2) Allows us to override them
3) Allows a scheme where any user can override them from the command line
For the last point consider someone running gcc on a heavily loaded
multi-user machine -- in that case there may be Gigs of ram but only a few
hundred meg available to the individual. It's not interesting to tune the
performance of gcc to the amount of physical RAM, but to the amount that
is likely to be available. At the same time we don't want gcc to try to
guess this since that can lead to hisenbugs.