Removing pure space

[Pip Cet <pipcet@gmail.com>]

I believe it is time to remove pure space from Emacs 28. It's a
needless complication which no longer provides clear gains. On the
other hand, it has clear disadvantages now that pdumper has become the
standard dumper: we end up putting about 3 megabytes of zero bytes
into each Emacs executable on GNU/Linux systems, for example.

Furthermore, the pure space code, even though it has been with us so
long, still has issues: see bug#46916 for one.

Most importantly, though, pure space requires a lot of complicated
code in places that are very hairy and difficult to modify; for
example, any change to the garbage collector has to be careful to
handle this special case correctly and (to the extent that this is
even possible) efficiently.

I am linking to a rebased patch which removes pure space from Emacs
28. It does not remove purecopy, it just modifies that function to
perform hash consing of values without purifying them:

https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-03/msg00335.html

Further steps would be to redefine purecopy to be a no-op, remove
calls to it from existing code, and finally to remove it
entirely. Those steps are not urgent, though.

Please note that this is almost entirely independent of any plans or
discussions to remove unexec support or require pdumper. When I last
looked into this issue, the Emacs 28 tree would not build with unexec
support, but, once modified to do so, it built just fine with the pure
space removal patch applied.

I have not been able to measure any performance changes with this
patch applied, but unfortunately I'm currently on a system unsuitable
for running reliable benchmarks. If this is a concern, any help
measuring the performance impact more accurately would be appreciated.

So, is anyone going to speak up to defend pure space?

Once that is settled, we can look at the actual patch and see whether
I made any mistakes in removing pure space.

Pip