This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [MAD SCIENCE EXPERIMENT]: Replace some libtool functionality with handcoded C


On Dec 5, 2003, at 2:30 AM, Andrew Haley wrote:

Mohan Embar writes:

What I'd like is to write a new makefile, using the latest
autoconf/automake, which: a) doesn't use libtool, and b) incrementally
links each java package with ld -r. The ld -r approach means that the
final link consists of linking a small number of large .o files instead
of a large number of small ones, which should be a lot faster. This
approach also stops it from tripping over command-line length limits,
and could perhaps later be extended to do something like
--enable-libgcj-multifile but for .o files.

An interesting alternative is to compile many .java files together, getting the benefit of interprocedural optimization. I know this will be prohibitively expensive on many machines, but I'd like to try on the high-end boxes.

Yeah, I don't propose to do that initially - faster libgcj linking and rebuilds is the main motivation, but linking packages-at-a-time would be a step in that direction.


I know that we don't have much interprocedural optimization at present,
but I hope that will change.

Ideally, we'd be able to do inter-procedural optimizations regardless of whether the procedures are in the same compilation unit, using a flag such as -fassume-compiled to tell the compiler they will end up in the same binary.


Regards

Bryce.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]