Re: Pure space

[Pip Cet <pipcet@protonmail.com>]

"Po Lu" <luangruo@yahoo.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Pip Cet <pipcet@protonmail.com> writes:
>>
>>> So, even if the decision is to keep pure space, can we at least make
>>> pure space overflow a fatal condition?
>>
>> Can't pure space be eliminated without affecting unexec?  It's not as
>> though every Lisp object in a dumped Emacs must be pure, and eliminating
>> read only objects would be a welcome change whether by itself or for
>> unexec builds.
>
> Btw, I get the impression that help facilities generate plenty of large
> strings that are ultimately dumped, so it would be useful to measure the
> size of pure space with and without the string deduplication
> optimization enabled, and decide whether it would be worth preserving in
> some form.

It's already disabled in scratch/igc (when HAVE_MPS is set), and IIRC I
didn't have to increase the pure space size...

Keep in mind that the current implementation only works one way: if we
dump "c", then "abc", both strings will be copied to pure space
completely. If we dump "abc", then "c", the second string will be
deduplicated to point at "abc" + 2.  I suspect this is the opposite of
what we need.

So it might be fairer to fix that first, and compare then. However,
once we start implementing rudimentary data compression for dumps, where
do we stop?

Pip