design choices for a loadable module interface

[Tom Yu]

Russ Allbery <rra at stanford.edu> writes:

> Given that both MIT and Heimdal are already successfully using exported
> data symbols as part of their ABIs, I'd like to hear more concrete details
> of what problems this is currently causing in practice before ruling this
> out.  I assume that you're proposing moving away from this to solve some
> set of problems that are currently affecting both major Kerberos
> implementations?

I can try to explain, but I have no empirical numbers on the
performance impact, and it might be minimal for our use cases.

Exporting a vtable as a data symbol forces some copy relocations to
occur.  In most shared object/library implementations I've read about
(ELF-based ones including Solaris), the text segment (executable
machine code) of a shared object may be multiply mapped at different
virtual addresses in different processes, while occupying the same
location in physical address space.  (This is one of the advantages of
shared objects.)  A vtable contains virtual address of functions.  If,
for example, a shared object has a function named "f1" whose address
is in a vtable that is exported, each process that has the text
segment of that shared object mapped will need a private copy of that
vtable, because it might have the text segment mapped at a different
virtual address than any other process that has that shared object
mapped.  The overhead of creating this private copy can have a
performance impact.

Incidentally, I'm fairly sure the same problem occurs if the shared
object exports an API that returns a pointer to a pre-filled vtable.
Call-by-numeric-identifier doesn't have this problem, but that suffers
from maintainability problems.