[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Loading tramp for dump goes into infinite regress

From: Andrea Corallo
Subject: Re: Loading tramp for dump goes into infinite regress
Date: Mon, 25 Jul 2022 20:11:14 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Lynn Winebarger <owinebar@gmail.com> writes:

> On Sun, Jul 24, 2022 at 12:31 PM Eli Zaretskii <eliz@gnu.org> wrote:
>> > From: Lynn Winebarger <owinebar@gmail.com>
>> > Date: Sun, 24 Jul 2022 12:20:47 -0400
>> > Cc: michael.albinus@gmx.de, emacs-devel@gnu.org
>> >
>> > it seems like something undesirable is going on between dumping and
>> > the native compilation unit.
>> I find this hard to believe.
> If I can recreate it in a more direct way on my personal machines, I'll put 
> in a bug with details including the required
> modifications to tramp.el (to remove the problematic require of 
> tramp-loaddefs).
> I also observed the same problem/fix with:
>   gnus/message
>   progmodes/gdb-mi
>   calc/calc-ext
>   gnus/gnus-sum
>   gnus/gnus-art
> More troublesome, though is that emacs segfaulted when it attempted to load 
> nxml/rng-pttrn, whether loading
> native-compiled, byte-compiled, or source.
> Otherwise, I was able to resolve the various issues (including some extensive 
> surgery on vc/ediff-X files to stamp out
> the circular loading).  I am going to have to do a real bootstrap to avoid 
> the "incoherent eln" error, though, and
> somehow force native compilation for all the libraries loaded in the dump 
> (that are not on the compiler's "forbidden"
> list, anyway).
>> Btw, you are aware that dumping *.eln files basically dumps just their
>> names, not their code?  And that, when you start Emacs after dumping,
>> it will load all of those *.eln files one by one, which takes time
>> (*.eln files are just shared libraries, like *.so files), and use up
>> shared-library and handle slots of the Emacs process?  So I'm not even
>> sure doing this would make sense from the performance POV: it could be
>> that startup will slower, not faster.
> I am aware that dumping the eln files produces an indirection to the shared 
> library, but not the details of the
> implementation.
> I would expect (or at least hope) that the effect of the evaluation that is 
> done on loading to be stored in the dump and
> for the shared libraries to get loaded into the process without repeating the 
> evaluation.  So things like the order of
> customization groups should be fixed.

While resurrecting from a dump an eln is mapped into memory if (at
least) a native compiled function noted in the dump was loaded from it.
So yeah the dumped state is preserved a no top level re-evaluation is

BTW I think so far we do not support re-dumping Emacs twice with native
code.  This is not a deep technical limitaiton, it's only because how we
fixup relative eln paths to support installed and non installed builds,
we should probably work on this limitation...



reply via email to

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