options for compiling large jars

Sat Dec 16 18:05:00 GMT 2006

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.