This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: High memory consumption compiling syntax.c


On Mon, Oct 01, 2001 at 12:43:46PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 1 Oct 2001 10:44:52 +0100
> > From: Neil Booth <neil@daikokuya.demon.co.uk>
> > 
> > Which compiler is causing the problem?  3.0 and 3.0.1 had problems
> > with runaway memory consumption if there is a lot of macro expansion
> > (it could easily chew up 10 to 20 Megs).  That was fixed in 3.0.2;
> > maybe you could try that?
> 
> No, I see this in all the versions since at least 2.7.2.1.  And I
> don't see any significant change in memory consumption between 2.95.3
> and 3.0.1, so the macros are probably not the reason.

You can try -fmem-report (in 3.x).  This will dump statistics on the
data remaining allocated in the garbage collection arena at the end of
compilation.  However, from what you report below, it rather sounds
like the runaway memory allocation is not through the garbage
collector, so this may not help.

...
> Fbackward_prefix_chars scan_sexps_forward {GC 5439k -> 1415k}

Notice how at no time does the GC arena get bigger than about 5MB.  If
you observed total footprint of 15MB that means we're allocating 10MB
of memory with malloc.

Based on previous similar reports, I'm inclined to suspect the basic
block tree.  Is the control flow in scan_sexps_forward unusually
complex?  Does it make use of computed GOTO?

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]