Page faults and libgcj.so startup time

[Per Bothner]

Jeff Sturm <jsturm@one-point.com> writes:

>                  libgcj    libstdc++    libc
> R_386_32          27006       1085       146
> R_386_GLOB_DAT     1340        174       149
> R_386_JUMP_SLOT    2299        270       452
> R_386_RELATIVE    41010       4374      1576
> 
> The first of these, R_386_32, is occupied by vtbl entries.  The
> R_386_JUMP_SLOT entries are lazily computed.  The R_386_RELATIVE entries
> seem to be fixups that are not based on a symbol, but rather the image
> base address.

I guess we can't avoid the vtable entries.  (One might think of some
vtable implementation using relative jumps that would help, but
I don't think it's practical.)

But it would be nice to understand better what R_386_RELATIVE is
used for, especially since they seem to be the biggest chunk.

Would compiling an entire package with a single compilation help?
I would think it would remove some relocations, since they are now
to the same .o file, and so may not need relocation at all,
especially if -Bsymbolic is used.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/