Re: Patch for Review: Build all libjava .class files at once (Updated Again)

[Andrew Haley <aph at redhat dot com>]

Bryce McKinlay writes:
 > On Wednesday, Sep 17, 2003, at 00:32 Pacific/Auckland, Jeff Sturm wrote:
 > 
 > > On Tue, 16 Sep 2003, Andrew Haley wrote:
 > >> If we're going to compile all the .calss files in a lump I'm tempted
 > >> to try the same thing with compiling libgcj from source.  We'd do lots
 > >> of inlining and avoid many PLT indirections.  I suppose compiling all
 > >> of libgcj this way would probably be out of the question, but pieces
 > >> with good locality might work well.
 > >
 > > I agree.  I had hoped libgcj could do this eventually.
 > 
 > I've considered this in the past - the problem with building multiple 
 > files as once is that it makes incremental rebuilds tricky. ie unless 
 > binutils learns to do proper incremental linking, we'll end up having 
 > to rebuild large chunks of the library after just changing one file. 
 > IMO as nice as it would be to have fast full rebuild times, its more 
 > important to have faster partial rebuilds - to speed up the 
 > code/compile/debug cycle.

Yes, but it's far more important to do the common thing well.  And the
common things is overwhelmingly just building the thing.  We could
still have a fallback way of building for developers.

 > As far as inlining and other such optimizations goes I think ultimately 
 > the front end will need to be able to do these even when its not 
 > building multiple classes at once

Inlining, yes, but it would make far more sense to do the job by
opening each file once.

 > - ie for the libgcj build we need to be able to tell it that
 > "java.*, gnu.*" are part of the current library and should be
 > optimized as such.
 > 
 > My proposed strategy for speeding up libgcj's build time is:
 > 
 > 1. Get rid of libtool. libtool sucks up a huge amount of time 
 > especially on platforms where the shell runs slower such as OS X. At 
 > some point soon I'd like to do this in combination with migrating the 
 > libgcj build to use the latest autotools.

I would love to be rid of libtool.  So much of build time is dominated
by it.

 > 2. Implement the bc-abi, which will reduce binary sizes and 
 > dramatically reduce public symbols/relocations and thus hopefully speed 
 > up link time.

We'll see.

Andrew.