This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch for Review: Build all libjava .class files at once (Updated Again)
- From: Bryce McKinlay <bryce at mckinlay dot net dot nz>
- To: Bryce McKinlay <bryce at mckinlay dot net dot nz>
- Cc: Jeff Sturm <jsturm at one-point dot com>,Andrew Haley <aph at redhat dot com>,Tom Tromey <tromey at redhat dot com>, <gnustuff at thisiscool dot com>,GCJ Patches <java-patches at gcc dot gnu dot org>
- Date: Thu, 18 Sep 2003 19:49:23 +1200
- Subject: Re: Patch for Review: Build all libjava .class files at once (Updated Again)
On Wednesday, Sep 17, 2003, at 16:54 Pacific/Auckland, Bryce McKinlay
wrote:
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.
I did a bit of profiling tonight and it looks like this is indeed the
case. Linking libgcj.so, ld spends over 96% of its time in the
following functions, all from bfd/merge.c. I'm wondering if a hashtable
is the right data structure here.
# opreport --symbols /home/bryce/gcc/i686-pc-linux-gnu/bin/ld
CPU: Athlon, speed 1544.83 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a
unit mask of 0x00 (No unit mask) count 10000
vma samples % symbol name
080a8c00 1264075 45.2845 last_eq
080b5b30 1010299 36.1932 htab_find_slot_with_hash
080a8b30 237515 8.5088 last4_eq
080a8d30 157330 5.6362 sec_merge_hash_lookup
0808c240 74944 2.6848 last4_eq
...
Regards
Bryce