> 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