[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Merging scratch/no-purespace to remove unexec and purespace
From: |
Eli Zaretskii |
Subject: |
Re: Merging scratch/no-purespace to remove unexec and purespace |
Date: |
Sun, 22 Dec 2024 15:07:24 +0200 |
> 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. There are definitely objects in
the pdumper file that are written to. Example: the *scratch* buffer.
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.
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).
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.
OTOH, what other reliable ways do we have? Whether a given object is
immutable is a programmer-level decision. I really don't see how this
decision could be made automatically by Emacs.
- Re: Merging scratch/no-purespace to remove unexec and purespace, (continued)
- Re: Merging scratch/no-purespace to remove unexec and purespace, Helmut Eller, 2024/12/17
- Re: Merging scratch/no-purespace to remove unexec and purespace, Helmut Eller, 2024/12/18
- Re: Merging scratch/no-purespace to remove unexec and purespace, Helmut Eller, 2024/12/21
- Re: Merging scratch/no-purespace to remove unexec and purespace, Gerd Möllmann, 2024/12/21
- Re: Merging scratch/no-purespace to remove unexec and purespace, Stefan Kangas, 2024/12/21
- Re: Merging scratch/no-purespace to remove unexec and purespace, Pip Cet, 2024/12/22
- Re: Merging scratch/no-purespace to remove unexec and purespace,
Eli Zaretskii <=
- Re: Merging scratch/no-purespace to remove unexec and purespace, Pip Cet, 2024/12/22
- Re: Merging scratch/no-purespace to remove unexec and purespace, Stefan Monnier, 2024/12/22
- Re: Merging scratch/no-purespace to remove unexec and purespace, Gerd Möllmann, 2024/12/22
- Re: Merging scratch/no-purespace to remove unexec and purespace, Pip Cet, 2024/12/22
- Re: Merging scratch/no-purespace to remove unexec and purespace, Helmut Eller, 2024/12/22
- Re: Merging scratch/no-purespace to remove unexec and purespace, Pip Cet, 2024/12/22
- Re: Merging scratch/no-purespace to remove unexec and purespace, Pip Cet, 2024/12/22
Re: Merging scratch/no-purespace to remove unexec and purespace, Pip Cet, 2024/12/18
Re: Merging scratch/no-purespace to remove unexec and purespace, Po Lu, 2024/12/17