Re: PLEASE COMMENT: faster elisp function calls
Jan Vroonhof wrote:
Glynn> Either you would need to relocate all of the pointers
(and
Glynn> Lisp code is primarily pointers) when you load the library,
Isn't this exactly what all the gung-ho stuff is all about.
I don't know. I'm not sure how it would help here.
Glynn> or every object which is referenced from the library
would
Glynn> have to have a specific address, which was known when the
Glynn> Lisp was compiled.
This is is about what 'a.out' style shared libraries where all about?
Yep. Libraries had fixed addresses, eliminating the need for
relocation.
May I propose a third option
We introduce a new "internal" pointer type, that is basically just
relative to the base adress of the packages. If the OS supports COW
that would allow loading to be a simple mmap followed by a link of the
external references. Furthermore it would increase the amount of
shared data between XEmacsen.
Of course this would also introduce a runtime penalty but I would like
to see how big this is. Moreover the XEmacs could do some kind of
just-in-time rewriting of the adress to the real pointer.
The problem as I see it is that a package's code typically contains a
large number of references to external symbols (and other objects, but
mainly symbols). Ordinarily, these get converted to pointers as the
package is read.
If the run-time values of these pointers were known when the package
was compiled (a.out library scenario), then you could just perform a
read-only, shared mmap() of the data.
OTOH, if the addresses are variable, then you either need to perform
an extra level of indirection per reference, or you have to relocate
the pointers at load time. The former would impose a (potentially
significant) run-time penalty, while the latter would eliminate the
possibility of a shared mmap().
P.S. I have no experience with lisp implementation, but suppose we
had
lexical scoping wouldn't most of the references be stack relative anyway?
Yes, references to local variables would be offsets from the frame
pointer (as opposed to global references which have to be saved and
restored by every let or function call).
It's references to external functions and global variables which would
require relocation.
--
Glynn Clements <glynn(a)sensei.co.uk>