This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: options for compiling large jars
- From: Andrew Haley <aph at redhat dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: java at gcc dot gnu dot org
- Date: Sat, 16 Dec 2006 11:21:12 +0000
- Subject: Re: options for compiling large jars
- References: <458356B1.2000006@bothner.com>
Per Bothner writes:
> What are the recommended options for compiling large jars?
> From what I can tell of Red Har's aot-compile script it
> appears to compile a .jar file without optimization.
I don't think so; that would be a bug.
> 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.
> 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.
> (One change is it no longer makes sense to compile to
> native from source if we also want .class files - instead
> just compile *.class after generating those.)
Yes, and -findirect-dispatch has never worked with our source-object
Java compiler.
Andrew.