Re: Page faults and libgcj.so startup time

[Jeff Sturm <jsturm at one-point dot com>]

On Thu, 29 Mar 2001, Bryce McKinlay wrote:
> It looks like *every* symbol in the library is being
> resolved by the linker immediatly at startup time, which would require
> most of the pages in the lib to be read by the linker.

Very interesting.  Thank you.

> Most of the
> startup cost is probibly in the linker's resolution code itself and
> not due to the page loading, except perhaps when the library is not
> already cached in memory.

Also libgcj is larger than your typical hardware cache, otherwise the
dynamic loading and symbol resolution is remarkably efficient.

> So question 1 is: what ever happened to lazy symbol resolution? I
> thought that the linker was supposed to be resolving symbols as code
> is executed? Why isn't this working?

It appears that RTLD_LAZY is used all right.  Certain symbols (_exit)
still aren't resolved until the process completes.  But the dynamic linker
appears to be overly aggressive, and process far more symbols up front 
than absolutely necessary.  I'd like to understand why.

Procedure symbols are initially mapped to a stub that performs binding
only when the stub is invoked and RTLD_LAZY is specified.  Data symbols
are another matter, and I'm not clear on how/when they are resolved.

Also, apart from dynamic linking, it appears that _Jv_RegisterClass causes
the class argument to be dereferenced as a side effect, which
probably defeats the purpose of clustering the constructors in one
section. That could be avoided by having the compiler precompute the class
hash, which might be a worthwhile optimization in its own right.

> Question 2 is: What are the disadvantages of "-Bsymbolic"? (the ld
> manual indicates that its an ELF-only thing for one). Assuming it can
> be made to work, are there any reasons why we wouldn't want to use it?

Sure it is ELF-only, but from the description I'd say it makes the library
work more like certain non-ELF targets (e.g. ECOFF) do.  Most non-ELF
dynamic libraries do not permit overriding symbols, for example.

My instinct is that making -Bsymbolic work may shake out some nonportable
aspects of libgcj along the way.

Jeff