bug#36447: 27.0.50; New "Unknown keyword" errors

[Daniel Colascione]

> On Mon, Jul 8, 2019 at 10:25 PM Noam Postavsky <npostavs@gmail.com> wrote:
>> I've switched byte-compile-cond-use-jump-table to nil for now, so you
>> shouldn't be hitting this anymore.
>
> Thanks.
>
>> > I know nothing about this, but did anybody want to fix this in a
>> > different way, or did the discussion just peter our?
>>
>> There were some suggestions about checking PURE_P or similar to see if
>> the copy is really needed, but then apparently PURE_P doesn't work at
>> all?  I've been meaning to check that out, because it seems like there
>> are still a few things which aren't making sense.
>
> It does seem like we've effectively given up pure space when we
> switched to pdumper. We still fill it and spend a lot of time making
> sure not to waste any, but it's then simply copied to the dump along
> with the rest of the dumped image.

We're at least combining identical objects, which is what this bug is about.

> It's still kept around in the final
> executable, so we're wasting quite a bit of disk space on it...

At least the executable pure space isn't paged in. I prefer not to waste
disk space, but wasting disk space without wasting memory is lower on my
list of priorities than other things.

> Most importantly, I think, the CHECK_IMPURE macro now does nothing
> (except waste a few cycles), and we can freely setcar what should be
> purecopied conses.
>
> (One thing we might do is introduce immutable conses, and use them for
> `read', pure space, and in a few other places).

We could use pureness information to relocate all the pure objects in the
dump so that we're less likely to take COW faults on them during runtime.
Right now, if a pure object and a regular object share a page in the dump
and we modify the regular object, we copy the pure object uselessly. Note
that we're not modifying these objects for GC, since we keep dump markbits
separate from the dump image (as we really should be doing for the heap in
general one day).