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

[Lynn Winebarger]

On Sat, Feb 4, 2023 at 3:08 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Lynn Winebarger <owinebar@gmail.com>
> > Date: Sat, 4 Feb 2023 14:55:27 -0500
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, eliz@gnu.org, 
> > emacs-devel@gnu.org
> >
> > > The node Advising Named Functions in the Emacs Lisp Reference says:
> > > [...]  Especially, Emacs's own source files should not put
> > >     advice on functions in Emacs.  (There are currently a few exceptions
> > >     to this convention, but we aim to correct them.)
> >
> > Are those exceptions considered bugs?
>
> Not necessarily.  But this should be used rarely and only if there's
> no better way.
>
> > Something in emacs is putting advice on call-interactively.  When I
> > extended the baseline dump to include essentially all libraries
> > included with emacs with native-compilation, it caused an infinite
> > (asynchronous) regress while compiling the trampoline for
> > call-interactively.  I wasn't aware of this until /tmp filled up.
>
> Is this with Emacs 28 or Emacs 29?

This was with 28.1 modified to support dumping with many pre-loaded
native-compiled files.
I disposed of that experiment (at least, of all copies I had access
to), which was created on my employer's systems.
I'm working toward implementing the functionality for the dev branch,
but my first step has been to create the infrastructure for testing my
work on build.opensuse.org against different versions of libgccjit.

As far as I know, emacs still doesn't support dumping arbitrary
native-compiled libraries at compile-time.  Which is too bad, because
the dumped version is a LOT faster to startup.  As per the other
recent thread (3x increase in startup time), loading eln files seems
to be considerably slower than loading elc files at startup, but in
dumped images the difference is probably the other way around.  I've
since approximated that dump with a byte-compiled version and the user
function dump-emacs-portable, but then I have to install before-init
hooks to systematically replace occurences of the user name and home
directory in variables and customizations to make the dump usable.
It's a kludge no distro would want to use.  Even then there are a
handful of libraries that have to be kept out of the dump (using bogus
"(provide <x>)" expressions) and then explicitly loaded in an
after-init hook after removing the bogus features. And they aren't
consistent with the ones that were problems for native-compiled
dumping.  But my point is, loading that byte-compiled dump takes
somewhat longer than loading the native-compiled dump that had twice
as many pre-loaded libraries.

Emacs needs a lot more work to really support compile-time dumping of
a larger set of libraries.  There are too many instances of code
evaluated at load time that should be evaluated in a before-init or
after-init hook, that depend on variables set in C code after the dump
file is loaded.  Or run-time services like dbus.  To really support
site-specific dumping, a robust analysis identifying that code and
transforming it appropriately would have to be performed either prior
to or as part of dump-mode.  It's non-trivial.  The changes to the C
code to deal with additional objects like text properties while
purifying are (or were) trivial by comparison.

Lynn