Page faults and libgcj.so startup time

[Bryce McKinlay]

Jeff Sturm wrote:

> > 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.

The LD_DEBUG=profile output from was reporting 35 million cycles or so spent
resolving 6000 or so symbols, IIRC, and much longer when libgcj.so wasn't
already cached in memory. That seems pretty efficient, but it would certainly
do a lot better if it didn't have to resolve so many symbols.

> > 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.

Me too. Could it have to do with the symbols in the class vtables perhaps? ie
maybe its just the virtual method symbols that are being looked up at load
time.

> > 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.

Sounds like it is worth investigating then. The error I was getting while
trying to use it was quite strange, though.

regards

  [ bryce ]