Re: MPS codegen

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Cc: gerd.moellmann@gmail.com,  acorallo@gnu.org,  emacs-devel@gnu.org
>> Date: Fri, 14 Jun 2024 21:26:37 +0200
>> 
>> On Fri, Jun 14 2024, Eli Zaretskii wrote:
>> 
>> > More generally, what exactly has been changed wrt loading from the
>> > pdumper file since commit 219f7d5?
>> 
>> The file is first loaded (mostly) as before; then all objects from the
>> hot section are copied to a MPS managed region.  Finally the hot section
>> is discarded.
>
> Can't we instead tell MPS not to move or manage any objects loaded
> from the pdumper file?  That's basically what we do now on master: any
> object loaded from the pdumper file is considered immutable.

The only way to prevent MPS from managing memory is to make it a root.
While roots are scanned, MPS stops the world, i.e. no other threads are
allowed to run. This is of cause bad for pause times, expecially with
the megabytes of the dump. Which is the root of the idea to copy the
dump - improve incremntality, reduce pause times.

>> My hypothesis is that discard_dump is the problem.  The hot section
>> probably contains something that isn't properly copied and
>> dump_discard_mem seems to be a bit different on Windows.  Why it even
>> works on Linux is a mystery to me :-).
>
> The Windows code decommits the memory region and makes it
> inaccessible.  By contrast, the posix_madvise method is AFAIU just an
> advisory, and doesn't necessarily make the memory inaccessible.
> Moreover, the Linux man page says:
>
>        In glibc, this function is implemented using madvise(2).
>        However, since glibc 2.6, POSIX_MADV_DONTNEED is treated as a no-
>        op, because the corresponding madvise(2) value, MADV_DONTNEED,
>        has destructive semantics.
>
> So to do on Posix systems the same as we do on Windows, I think we
> need to call madvise with MADV_DONTNEED, even if posix_madvise is
> available, and also call mmap with PROT_NONE.  Do you agree?  If we do
> that, does the GNU/Linux build still work, or does it also crash on
> startup?

I still think we should first establish that that is indeed the problem.
Please see my other mail.