design choices for a loadable module interface

[Russ Allbery]

Tom Yu <tlyu at MIT.EDU> writes:

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

Ah, thank you for the explanation!

If I understand the issue properly, it would not apply if the module
retuns a pointer to a vtable that's constructed on the fly (since then the
function addresses would already be properly resolved for that instance of
the module), although that of course is more effort to do in the module.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>