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

[Bryce McKinlay]

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.

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 - 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.

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


> It'll solve part
> of the linking problem, that of long command lines, and the overall 
> linker
> step may need a bit less memory.  And it'll help avoid a particularly
> onerous libtool bug in which libtool invokes ld -r directly, using the
> wrong emulation on some targets (ppc64).
>
> It'll also eliminate some duplicate Utf8's, shrinking libgcj.so 
> slightly.

We already eliminates duplicate Utf8's if the linker supports it (ie 
newish GNU binutils). Actually, I'm suspicious that the string merging 
is partly responsible for the slow link time! If it does account for a 
large proportion of the link time we should investigate alternative 
means for the class metadata under the bc-abi.

Regards

Bryce