unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Pure space
@ 2024-08-16 19:07 Pip Cet
  2024-08-17  6:18 ` Eli Zaretskii
  2024-08-17  8:16 ` Po Lu
  0 siblings, 2 replies; 29+ messages in thread
From: Pip Cet @ 2024-08-16 19:07 UTC (permalink / raw)
  To: emacs-devel

Hello everyone,

can we revisit the question of whether we still want pure space? I just
tracked down another pure space related bug, and I believe there's ample
evidence now that it's slowing down not just me but other developers:

* Gerd no longer uses purespace. He's added support for purespace to the
  MPS branch, but I imagine this took a while.
* Danny's recent regexp patch included some code for pure space, which I
  believe was unnecessary effort
* Adding headers to pure space objects in the MPS branch required some
  effort

I believe everyone who knows the source code can agree that pure space
adds significant complexity to the code, and I'm afraid that fixing the
remaining bugs (such as 'valid_lisp_object_p' returning 1 for all
objects that happen to point anywhere into pure space) would make it
even more complex.

I think it's particularly problematic to attempt to survive pure space
overflow: that means there are now "pure" objects for which PURE_P
returns false, and that's what caused this latest bug.

I keep running into pure space overflows that I think are caused by
going back and forth between configurations with and without native
compilation (without doing a full make bootstrap, which fixes
things). I'm willing to accept that's my fault, but I shouldn't have to
track down segfaults caused by that.

So, even if the decision is to keep pure space, can we at least make
pure space overflow a fatal condition?

I'd like some indication of how people see this before reopening
scratch/no-purespace...

Thanks
Pip





^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2024-08-17 15:41 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-08-16 19:07 Pure space Pip Cet
2024-08-17  6:18 ` Eli Zaretskii
2024-08-17  6:59   ` Stefan Kangas
2024-08-17  8:14     ` Po Lu
2024-08-17 12:10       ` Stefan Kangas
2024-08-17 12:53         ` Eli Zaretskii
2024-08-17 13:36           ` Po Lu
2024-08-17 14:12             ` Eli Zaretskii
2024-08-17  8:45   ` Pip Cet
2024-08-17 10:51     ` Eli Zaretskii
2024-08-17 11:38       ` Pip Cet
2024-08-17 13:13         ` Eli Zaretskii
2024-08-17 13:26           ` Pip Cet
2024-08-17 14:29             ` Eli Zaretskii
2024-08-17 14:35               ` Pip Cet
2024-08-17 13:11     ` Stefan Kangas
2024-08-17 14:30       ` Pip Cet
2024-08-17 15:34         ` Andrea Corallo
2024-08-17 15:41           ` Pip Cet
2024-08-17  8:16 ` Po Lu
2024-08-17  8:28   ` Po Lu
2024-08-17  8:31     ` Po Lu
2024-08-17  8:57     ` Pip Cet
2024-08-17 11:06       ` Eli Zaretskii
2024-08-17 10:45   ` Eli Zaretskii
2024-08-17 11:46     ` Po Lu
2024-08-17 12:49       ` Eli Zaretskii
2024-08-17 13:44         ` Po Lu
2024-08-17 14:17           ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).