RE: dynamic library cost (was RE: libtool, java woes)

["Boehm, Hans" <hans_boehm at hp dot com>]

Isn't PIC code in the library only part of the story?  Even if you
unconditionally compile the library as PIC, there's still the issue of
whether the client can directly branch it, or branch to an indirect branch
to the routine (X86) or branch to a more complicated trampoline (IA64).  On
IA64, much of the time seems to go into the trampoline code, though there
seems to be potential for optimization there.  The code is essentially
position independent in all cases.

I'm not sure how well typical X86 hardware handles the
branch-to-indirect-branch sequence.

Hans

> -----Original Message-----
> From: Alexandre Oliva [mailto:aoliva@redhat.com]
> Sent: Tuesday, April 10, 2001 1:22 PM
> To: Boehm, Hans
> Cc: tromey@redhat.com; Jeff Sturm; java@gcc.gnu.org; gcc@gcc.gnu.org
> Subject: Re: dynamic library cost (was RE: libtool, java woes)
> 
> 
> On Apr 10, 2001, "Boehm, Hans" <hans_boehm@hp.com> wrote:
> 
> >> From: Alexandre Oliva [mailto:aoliva@redhat.com]
> 
> >> We either need libsupc++ to be a shared library, that both 
> libstdc++
> >> and libgcj depend on, or have libgcj depend on libstdc++.
> 
> > I'm seeing significant overheads as a result of dynamic library
> > calls.
> 
> In this particular case, it would make no difference at all: libsupc++
> is already compiled as PIC, even though it's a static library.
> 
> -- 
> Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
> CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
> Free Software Evangelist    *Please* write to mailing lists, not to me
>