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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org,  akrl@sdf.org,  larsi@gnus.org,  rlb@defaultvalue.org
> Date: Sat, 28 Jan 2023 12:42:08 -0500
> 
> >> >> 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.

People will use inhibit-automatic-native-compilation even if their
problem is not non-writable HOME directory.  So the fact that
non-writable HOME is rare tells us nothing about the frequency of
these situations.

> And we do have a solution: pregenerate the trampolines.

So you are saying that the "prevent writing trampolines" part of
inhibit-automatic-native-compilation is not needed?

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

Thanks, but I don't see how that answers my question.  Unless by
"inside the subr" you mean we should change the implementation of
defsubr?  If so, this is definitely not for Emacs 29, and we should
discuss it separately.  My question about what to do with trampolines
was about Emacs 29.