[15938] in Kerberos_V5_Development
Re: design choices for a loadable module interface
daemon@ATHENA.MIT.EDU (Russ Allbery)
Tue Jun 29 18:41:10 2010
From: Russ Allbery <rra@stanford.edu>
To: krbdev@mit.edu
In-Reply-To: <ldvd3v932dd.fsf@cathode-dark-space.mit.edu> (Tom Yu's message of
"Tue, 29 Jun 2010 18:22:54 -0400")
Date: Tue, 29 Jun 2010 15:41:03 -0700
Message-ID: <87fx05fon4.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Tom Yu <tlyu@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@stanford.edu) <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
