Re: Unit at a time and C PCH

[Jan Hubicka <jh at suse dot cz>]

> >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
> 
> >> Java use no-unit-at-a-time by default because large bytecode units
> >> explode in memory.
> 
> Andrew> It is possible that identifier GC fixes this.  The explosion
> Andrew> was mainly identifiers.
> 
> I did not realize that -- cool.
> 
> Do we have a canonical gcj test case for this?
> 
> If it is a .jar file, I think I probably don't care too much.  My
> reasoning here is that users already have to split jars to avoid TOC
> overflows.

OK, on the jar file I have, I get about 4.5GB (as seen on TOP output)
for -fno-unit-at-a-time -O0.  -O0 -funit-at-a-time ends up being killed
on the 64bit box with 12GB of RAM.  However after parsing the footprint
seems to be "just" about 3.8GB of GGC memory so unit-at-a-time
compilation ought to fit in about 4GB of RAM too. Somehow we later
manage to consume 7GB at compilation stage, perhaps as result of
excessive inlining or something else.

Well, it is pretty steep in both cases and obviously gets worse with
unit-at-a-time. I will try to get some data on where the memory goes,
but it is difficult given that the compilation does not finish.  It is
at tuples branch, I will test mainline too.
> 
> If we have a monster .class file, then that would be interesting.

Concerning monster .class files, I think memory usage should be
same as for C/C++, so there should not be big problem.  So perhaps this
is not showstopper for switching to unit-at-a-time?

> 
> Note that gcj does not use PCH at all.  So, it is no problem for us if
> PCH and no-unit-at-a-time are incompatible.

Problem here is maintaibility of two significandly different compilation
modes.  When only Java use no-unit-at-a-time, we will probably end up
breaking it even more.

Honza
> 
> Tom