Re: Merging scratch/no-purespace to remove unexec and purespace

[Pip Cet]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Date: Sun, 22 Dec 2024 11:12:30 +0000
>> Cc: Helmut Eller <eller.helmut@gmail.com>,
>>  Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
>> From:  Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
>>
>> 1. choose a "tenured" set. I would hazard a guess that most objects in
>> the pdumper file are usually not actually written to, ever, so maybe we
>> could even get away with starting with a universally-filled "tenured"
>> set.  We could use, in essence, PGO to do so, by identifying call stacks
>> for objects that are modified and excluding them from the "tenured" set
>> based on the call stacks when the real Emacs is built.
>
> I don't think your guess is correct.

My proposal was about hints (or guesses), not about hard promises.  I
see no reason to prefer the latter to the former: on the C code side of
things, it causes complexity, because we need to deal with broken
promises somehow (currently, we just crash, in some cases).  I'm
convinced it's worse for performance, because there are many
mostly-immutable-but-someone-might objects which are still worth
optimizing for.

As for my guess, it is correct.  I guessed that few objects are written
to, so we can give a blanket *hint* that an object in the pdump is
probably not going to be mutated.  It's obviously true that some objects
are, so inevitably some of the hints are going to be incorrect, but
that's why they're just hints.

> There are definitely objects in the pdumper file that are written to.

Of course, but that wasn't the question.

> Historically, the purecopy calls that created pure objects have their
> legacy from the unexec era, when any Lisp object generated in temacs
> was dumped into the emacs binary, and originally ended up in the BSS
> section (and was shared between different emacs instances running on
> the same system).  It is thus possible that quite a few of pure
> objects were there "by accident", and there's no need to keep them
> from temacs stage.  We already started to get rid of some of those,
> but meanwhile did that only where pdumper caused trouble.  IOW, we are
> now in an interim state where some dumped objects don't need to be
> dumped at all, but should be recreated anew when Emacs starts.
>
> So going by dumped objects is IMO following the wrong lead.

I agree.

> It would make sense to have a special API for defining objects that
> need not be scanned by GC, in effect reintroducing pure space (but
> with a different name and only for objects that are truly immutable).

I disagree.  I don't see the need for the "hard promise" character of
that API.  Hints seem to be sufficient, they cause much less trouble,
and we can generate them (semi-)automatically because an incorrect hint
would cost some performance but wouldn't crash Emacs.

Most importantly, whether an object needs to be scanned by GC or not is
very difficult to decide, and liable to change, and then we have to
check all the API calls, and if we make a mistake it'll result in
crashes.

We know that would happen because we already did it, with purespace, and
now master-branch Emacs is crashable.

> However, it sounds like this adds back one reason why we wanted to get
> rid of purespace: the tedious and error-prone job of identifying such
> objects and marking them in the sources.

That's why I think hints/guesses are the only option: then we can just
ignore them, or lose some performance because of wrong hints, or correct
them automatically, or whatever, without ever crashing Emacs.

> OTOH, what other reliable ways do we have?  Whether a given object is

With hints, we don't need to be reliable, we just need an "oops, turns
out not to be read-only" fire escape, which isn't that hard to do.

> immutable is a programmer-level decision.  I really don't see how this

Why encourage programmers to even consider the question, though?  I
think of it as analogous to deciding the right size of a C integer: Lisp
avoids forcing the programmer to make that decision, and it's a better
language because of that.  Guesses or hints are sufficient for
performance, and they maintain the flexibility of simply mutating an
object when we need to.  They're also better for performance.

(Char tables can be "sealed" so we don't have to scan the entire
table, just the values used in it (and each value only needs to be
scanned once).  Mutation would mean unsealing them, and then we could
re-seal them after another GC cycle or two without modfications.  That's
the kind of approach we should generalize, not "I promise not to modify
this object".)

> decision could be made automatically by Emacs.

Hints (or guesses) can be done automatically.  Hard promises, no.

I'm comfortable giving up on hard promises for good.

Pip