bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded

[Stefan Monnier]

>> so the problem doesn't affect only byte-compiled objects but also
>> overlays, markers, windowconfigs, chartables, and fonts, AFAICT.
> True, but then, those don't make much sense as hash keys in an
> equal-based hash table.

Comparing markers with `equal` does make some kind of sense.
And `sxhash-equal` needs to be consistent with it, regardless if we
think it makes sense to index an equal-hash-table with markers (or
objects containing markers).

> I don't think bytecode objects make sense as
> hash keys in an equal-based hash table,

I agree that comparing function objects is fundamentally unreliable, yet
we do that in several places in Elisp: it's not super common, but it's
not rare either, and having a better approximation of "behaves
identically" than `eq` is occasionally useful.

> on its position, for example, makes little sense: when the marker
> moves, the hash value would change.

Comparison with `equal` suffers from this problem in many more cases
than just markers (cons cells, vectors, strings, ...).

> (deduplicating identical bytecode objects used as constants in other
> bytecode objects appears to save quite a bit of space),

I'm curious where you've seen that (I haven't looked at it, but indeed
it's quite possible that the byte-compiler "often" ends up generating
identical byte objects).


        Stefan