Re: GCC 4.1: Buildable on GHz machines only?

[Per Bothner <per at bothner dot com>]

Mark Mitchell wrote:
> Building libjava takes forever on any platform, relative to the rest of 
> the compiler build.

In addition to fixing/replacing libtool (could it be rewritten as a C
program?) there are a number of other known gcj performance problems.

When compiling A.java, gcj needs to read a lot of other classes that A
depends on.  It seems to be reason a lot more classes than it needs to:
it is a lot less agressive about loading a class than it should be.

On the other hand, much time spend improving gcj performance might
be wasteful it it will be replaced by Tom's new gcjx.

One way to speed up libcgj compilation by quite a bit would be to
compile more than one .java file at a time.  For example:
  gcj -c java/util/*.java -o java-util.o
This reduces libtool overhead, reduces the duplication in reading
dependencies, and probably reduces link overheads.  It can also
produce better code, since intermodule references get trurned into
intramodule references.  This just requires Makefile-hacking.
Disadvantages:
- Static linking (which we don't really support very well anyway)
might causes some classes to be needlessly linked in.
- Compiling multiple classes at once might increase virtual memory use.

I think the net benefit could be large - an experiment would be
quite worthwhile.  Perhaps somebody could write a post-configure
script to munge the Makefile and give us some numbers.

Ideally, there'd be a configure flag to control "chunking".
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/