Re: Suppressing native compilation (short and long term)

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

On Sat, Oct 15, 2022, 10:02 AM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

>
> > I don't think we should depend on architecture-dependent code.  It
> > would mean we don't support new platforms until someone writes such
> > code for them, for starters.  It's against our development tendencies
> > for the past 10 years at least.
>
> I know, I know.  From a technical point of view, it's The Right Thing to
> do, I think, tho: it will eliminate all the other issues surrounding
> trampolines (e.g. disk space to store trampolines, dependence on
> libgccjit for the creation of those trampolines, fork bombs) and will be
> much more efficient both in CPU time and memory use (we don't care too
> much, because trampolines are hopefully not too frequents, so we live
> with them being quite inefficient in the time to create them (and set
> them up, via dyn-linking) and in their memory use).
>
> But yes, the architecture-dependence is a serious problem, which is why
> we've so far avoided that solution.


Didn't you, a couple of years ago, suggest generating generic trampolines
(per function signature), compile those with gccjit, then just use them as
needed rather than compiling separate trampolines for every subr?
Presumably the system would still occasionally need to compile a trampoline
for a new signature, but the generic trampoline would not be named so it
couldn't cause an infinite recursion by being advised before being compiled.

Lynn

[-- Attachment #2: Type: text/html, Size: 1976 bytes --]