emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Finalizing 'inhibit-automatic-native-compilation'


From: Stefan Monnier
Subject: Re: Finalizing 'inhibit-automatic-native-compilation'
Date: Sat, 28 Jan 2023 12:42:08 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

>> >> For trampolines, in the short term we should probably add a fallback to
>> >> use an eln-cache in the `temporary-file-directory` (i.e. use the code
>> >> we currently use when `inhibit-automatic-native-compilation` is non-nil).
>> >
>> > This have two problems:
>> >
>> >   . it cleans up only on Posix platforms
>> 
>> Yup.  I hope it's "good enough" for our immediate needs, tho.
>
> Not from my POV, no.

I assume using Emacs with a non-writable HOME/eln-cache directory is
quite rare, and if (in addition to the that) the
`temporary-file-directory` is always the same, then those trampoline
files that we fail to delete won't keep accumulating ad-infinitum.
So the problem is hopefully rare.

And we do have a solution: pregenerate the trampolines.

>> No: what I'm suggesting is to pregenerate the trampolines before we know
>> if we'll need them (a bit like `make trampolines`), but to place them
>> alongside the code that might need it, so there's no additional "small"
>> files containing nothing but a trampoline.  Instead we add tiny chunks
>> of code (the trampolines) to other `.eln` files and we do it at a time
>> where we know we have GCC at hand.
> What do you mean by "alongside"?  The code which needs trampolines is
> the code which advises primitives, and that is written in C.  Where
> would "alongside" be in that case?

We need trampolines because we call (from .eln files) some functions via

    <functionvar> (...)

instead of looking at the function cell of a symbol, checking what kind
of Lisp_Object it holds, etc...

When an advice is installed (i.e. when the function cell of the symbol
is modified), we need to update the `functionvar` so it points to
a trampoline which does the dance of "looking at the function cell of
a symbol, checking what kind of Lisp_Object it holds, etc...".

So, we could pregenerate the trampoline and store it directly inside the
subr that's originally stored in the symbol's function cell.
So instead of (comp-subr-trampoline-install SUBR) having to generate the
trampoline, it would find it in one of the fields of the subr struct.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]