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: Lynn Winebarger
Subject: Re: Finalizing 'inhibit-automatic-native-compilation'
Date: Mon, 6 Feb 2023 10:26:41 -0500

On Mon, Feb 6, 2023 at 5:15 AM Andrea Corallo <akrl@sdf.org> wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Lynn Winebarger <owinebar@gmail.com>
> >> Date: Sat, 4 Feb 2023 17:05:19 -0500
> >> Cc: rms@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> >>
> >> On Sat, Feb 4, 2023 at 3:08 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >> >
> >> > > 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 asked because Emacs 29 adds some changes specifically intended to
> > solve the problem of infinite recursion in trampoline compilation.
> >
> >> As far as I know, emacs still doesn't support dumping arbitrary
> >> native-compiled libraries at compile-time.
> >
> > What problems do you see if you try?  AFAIR, if you tweak
> > native-comp-eln-load-path so that the *.eln files you want to dump are
> > directed to the ../native-lisp directory relative to where the Emacs
> > binary lives, then dump Emacs, loading such a dumped Emacs should
> > work.
> >
> > Andrea, am I missing something?
>
> I think he might be talking about re-dumping Emacs?
>
> Otherwise no, I'm not aware of anything you are missing.  We can dump
> any library we want just loading it before the dump (we modified the
> list of dumped libraries just doing this many times in the last two
> years).
>

I'm wondering if we are talking about the same thing.  It's not enough
that the eln files exist after the dump.  For the benefits I'm
discussing, the eln files have to be generated and placed in
native-lisp (or preferably native-lisp/preloaded) *before* dumping,
not just at run-time.  The eln files must actually be loaded into
memory before the dump so that all the associated work is skipped at
start-up.

If I had meant that the byte-compiled dump happened with eln files
slated to be loaded at startup time as though they had just been
asynchronously compiled, then I would also expect there to be minimal
benefit.  Getting those eln files generated and in the right place
*before* the dump takes some effort.

Lynn



reply via email to

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