Re: Changes in GC and in pure space (was: [Emacs-diffs] master 5d4dd55: Fix lifetime error in previous patch)

[Eli Zaretskii]

> From: Pip Cet <address@hidden>
> Date: Mon, 22 Jul 2019 19:05:43 +0000
> Cc: address@hidden, address@hidden
> 
> > The same goes for removing the pure space, IMO: another core feature
> > whose existence and traits many parts of Emacs came to take for
> > granted.
> 
> Let's not remove pure space for Emacs 27.
> 
> (The traits of pure space changed significantly, with the introduction
> of pdumper: CHECK_IMPURE is now a nop rather than a valuable debugging
> aid, and PURE_P is always false. That is something we should mention
> somewhere, along with all the good NEWS, because it will make Emacs 27
> harder to maintain.  But that's all we should do, I think, document
> the odd state we're in now and resolve to change it when it is more
> appropriate to do so.)
> 
> > I'm all for improving GC and simplifying our memory management, but
> > please keep the above in your minds when you play with this stuff.
> > Especially as, judging by the changes you are making, the details and
> > indeed some of the aspects of the idea of the changes, are not yet
> > sufficiently clear/finalized.
> 
> I'm forced to agree, as far as my ideas are concerned.
> 
> Eager rehashing of hash tables: needs to be timed precisely right for
> user-defined dumped hash tables to work, as Paul apparently wants them
> to, and my current proposal isn't (but let's fix Fclrhash to work on
> non-rehashed hash tables).
> 
> Hash tables without internal free vectors: change the interpretation
> of the hash table API (:size has to be reinterpreted to remain
> meaningful), and some trade-offs about when to use hash tables.
> 
> Four tag bits for "annotated" (e.g., immutable) objects: very far from
> ready, and problematic on 32-bit machines (perhaps this is no longer a
> concern for Emacs 28...)
> 
> Turning pseudovectors into their own tag type, as miscellaneous
> objects: not convinced it's worth the change, yet.

We can still have these on a branch, or on several branches.

> > An alternative would be to make these changes on a branch, and merge
> > that branch when it is sufficiently stable and mature.  Please
> > consider this possibility.  After all, these two issues are not
> > terribly urgent to fix (unlike, say, the unexec thingy).
> 
> I'm not quite sure which "unexec thingy" you're referring to.

A.k.a. "pdumper".