Re: options for compiling large jars

[Andrew Haley <aph at redhat dot com>]

Per Bothner writes:
 > Andrew Haley wrote:
 > >  > I can understand that, because it because when I compile
 > >  > kawa.jar without optimization it is fairly quick (2m17s),
 > >  > but when I compile with -O1 it takes forever.
 > >  > Even using -fno-unit-at-a-time doesn't seem to help.
 > > 
 > > You're short of RAM?  AFAICS compiling with optimization takes about
 > > three times as long as compiling without, as long as you don't run
 > > short of RAM.
 > 
 > That is presumably the problem.  I have 1Gb on my primary development
 > laptop, and similar amounts (0.5G - 2Gb, I think - what's an easy way
 > to check a running Fedora system?) on my other computers.
 > 
 > But I don't think it is acceptable not being able to build Kawa
 > in a reasonable time using a 1Gb machine ...
 > 
 > (If gcc used more memory- and locality-efficient data structures
 > we could probably do whole-program compilation of large programs
 > without swapping.  But that is a different discussion.)
 > 
 > >  > What I've done with Kawa before is compile one package
 > >  > at a time, and that seems to work fairly well.
 > >  > But I'm trying to figure out what changes are appropriate
 > >  > in the new world, where we use ecj and gcj-dbtool.
 > > 
 > > You can continue to compiler things in the same way, as long as you
 > > use -findirect-dispatch and -Bsymbolic.
 > 
 > Ok, I'll do that.

I forgot to say: aot-compile also automates all the messing about with
gcj-dbtool.  aot-compile should be merged with gcj-dbtool, and all
this would be much cleaner.

Andrew.