Re: Failure to build libjava on 512MB machine

[Andrew Haley <aph at redhat dot com>]

Mark Wielaard writes:
 > On Tue, 2007-01-30 at 12:55 -0700, Tom Tromey wrote:
 > > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
 > > 
 > > Andrew> Anyway, I tried again, this time with the right file, and it took
 > > Andrew> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
 > > Andrew> and indeed, it does want a lot of memory - at peak some 550m.  It'll
 > > Andrew> be smaller on a 32-bit box, but not much smaller.
 > > 
 > > I suppose with some awful build hacking we could split this .o into
 > > multiple parts.  I'm fine with the situation as it is, myself, but I
 > > will do this if the consensus is that we should.
 > 
 > It does look like we are scaring away some people with the long
 > build times and memory hungry build of libjava. I only started
 > building libgcj again recently when I got a
 > 3Ghz/64-bit/dual-core/2GB machine. And even on that box an
 > compile/install/test cycle is not something I want to do more than
 > once or twice a day.

I'm surprised: the libgcj build takes about 15mis on my box, which is
similar to yours.

 > Having a 'light' build would be really good. Even if it is just a
 > configure option that creates an unoptimized build.
 > 
 > Has someone looked into why gcj takes so much memory/time to compile?

Yes.  Lots of times.  It's not entirely to do with gcj: it's mostly
time spent in the emiddle-end.  gcc, g++, etc do the same.  The main
difference with gcj is that we're compiling bigger files.  

One thing that could be improved is the quality of trees geneerated by
the gcj front-end, which are unnecessaily verbose, but that would
shave a few percentage points of the total time/space.

 > And might recent changes in tree-ssa have increased memory and compile
 > time?

Yes, I think so.  Recent changes to the optimizers do cost compile
time and space.  I think the authors are aware of that.

Andrew.