From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14682 invoked by alias); 4 Feb 2003 00:05:20 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 14646 invoked from network); 4 Feb 2003 00:05:19 -0000 Received: from unknown (HELO hollebeek.com) (216.178.83.228) by 172.16.49.205 with SMTP; 4 Feb 2003 00:05:19 -0000 Received: (from tim@localhost) by hollebeek.com (8.9.3/8.9.3) id QAA18847; Mon, 3 Feb 2003 16:29:08 -0800 Date: Tue, 04 Feb 2003 00:05:00 -0000 From: Tim Hollebeek To: Tim Josling Cc: gcc@gcc.gnu.org, Neil Booth , Mike Stump , Benjamin Kosnik Subject: Re: GCC 3.3, GCC 3.4 Message-ID: <20030203162908.A18834@hollebeek.com> Reply-To: tim@hollebeek.com References: <1043976898.27601.ezmlm@gcc.gnu.org> <3E3E226F.1DA63EDF@melbpc.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <3E3E226F.1DA63EDF@melbpc.org.au> X-SW-Source: 2003-02/txt/msg00158.txt.bz2 > Use a simple contiguous allocator, up to a certain amount of memory. If that > runs out, restart the compile using ggc-page. Most compiles would not be > affected, and the few that do need GC will get it without too much overhead. > You could have an option -ggc-force to avoid the restarts. it would be even more interesting to find a (perhaps file size based) heuristic that can predict memory needs well enough to usually get the decision right up front. -Tim