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: Excessive resource consumption (GCC 3.1)




On Thu, 9 Aug 2001, Gerald Pfeifer wrote:

> A sparc-sun-solaris2.6 box I considered dedicating to automatic regression
> testing failed it's first experiment:
>
>   stage2/xgcc -Bstage2/ -B/sw/test/gcc/SunOS/sparc-sun-solaris2.6/bin/ -c -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes   -DHAVE_CONFIG_H    -I. -Ijava -I/sw/test/gcc/cvs/gcc -I/sw/test/gcc/cvs/gcc/java -I/sw/test/gcc/cvs/gcc/config -I/sw/test/gcc/cvs/gcc/../include /sw/test/gcc/cvs/gcc/java/parse.c -o java/parse.o
>   cc1: Cannot allocate 8744016 bytes after allocating 27115520 bytes
>   gmake[2]: *** [java/parse.o] Error 1
>   gmake[2]: Leaving directory `/tmp/OBJ-0808-0716/gcc'
>   gmake[1]: *** [stage3_build] Error 2
>   gmake[1]: Leaving directory `/tmp/OBJ-0808-0716/gcc'
>   gmake: *** [bootstrap-lean] Error 2
>
> This is a box with 80MB of main memory and 160MB of swap.
Hmmmmm. Maybe it's time i go clean up some more memory leaks?
We still have quite a few, even in our use of simple data structures like
sbitmaps (we leak 2 sbitmaps per function we compile, i haven't quite
tracked down where yet, or what size). I wonder how much we leak more
frequently used stuff.
>
> Am I the only one finding this unacceptable?
No, I think it's just plain sad, to be honest.
But it's not surprising, considering a lot of the compiler code is
not exactly the best thought out in the world (no offense to anyone, it's
more hindsight and bitrot i would imagine, than anything else)
Quick, count how many loops we have that iterate over RTL, performing some
slightly different thing.  Apparently, it was better to copy these 30
lines of code to recursively iterate, to 5000 places, than make up
static inline'd iterators for RTL or something, using cookies to save
state, and do it in 5 lines of code.
It would seem at first to be a different problem than memory leaks, but
it's the lack of function reuse, opting instead for massive code
pasting, that helps contribute.
Even if you fix one memory leak, you have to really look to hunt down all
the other places that code was copied, and fix it elsewhere.
Same with improving small optimizations.
It ends up diverging everywhere over time (since someone hits one place
and misses 3, and then someone else hits 2 of the 4, and misses the other
2, etc), so if someone wanted to go and merge them, they have to try to
figure out which is the right one (or the right bits from each).

Of course, I know no one *intends* to do any of this, or is stupid, or
anything like that, but the next time you are in a
random file, and see the same code 50 times, consider commoning it, at
least in that file.
And i'll be submitting RTL iterators sometime tomorrow, before someone
says i should stop complaining.

Personally, I find something like:

void mark_mem_regs_used (insn, used)
rtx insn;
sbitmap used;
{
	rtx_iter_cookie cookie = 0;
        rtx reg;
	while ((reg = get_next_reg (insn, &cookie)) != NULL)
		SET_BIT (used, REGNO (reg));
}
much easier than the 29 lines of code (I counted) it requires to do the
same thing.
Maybe i'm just weird.

(Though they are harder on the garbage collector. We could just introduce
the limitation that the cookies don't survive collections until we have a
nursery or something, and allocate them from a special pool.
I just didn't want to introduce another obstack.)

 > PS: Mark,
this is plain C code, not C++, else I would have waited for
> the future work you had announced (and certainly until the release of
> GCC 3.0.1) before reporting this.  Your load is already skyrocketing
> beyond bounds, but this seems someone else's stuff.
>


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