Re: master 0fc4989: Tweak GC performance if !USE_LSB_TAG

Re: master 0fc4989: Tweak GC performance if !USE_LSB_TAG

[Pip Cet]

On Tue, May 26, 2020 at 10:48 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> branch: master
> commit 0fc4989f34bdaf1bc443d05ece886ea91e7bc9cc
> Author: Paul Eggert <eggert@cs.ucla.edu>
> Commit: Paul Eggert <eggert@cs.ucla.edu>
>
>     Tweak GC performance if !USE_LSB_TAG
>
>     Performance issue reported by Eli Zaretskii (Bug#41321#149).
>     * src/alloc.c (GC_OBJECT_ALIGNMENT_MINIMUM): New constant.
>     (maybe_lisp_pointer): Use it instead of GCALIGNMENT.

Why don't we just set GCALIGNMENT to 8/4 on those platforms? We'd
waste a few bytes of pdumper space, but that's the only disadvantage I
see.

I don't think anyone will get the difference between
GC_OBJECT_ALIGNMENT_MINIMUM and GCALIGNMENT, and the subtlety that
pdumper objects are relevant to GC, but aren't aligned to
GC_OBJECT_ALIGNMENT_MINIMUM.

I confess I don't fully understand when pdumper.c actually aligns only
to GCALIGNMENT, but I think there's a theoretical bug here: if a
misaligned pdumper object is used as a key in a weak-key hash table,
and the only reference to the key is on the stack, and that reference
is split so we rely on mark_maybe_pointer, the hash cell entry might
get collected even though it should be kept alive. I think pdumper
might also be buggy on GCALIGNMENT=1 platforms that actually _require_
greater alignment than 4 for some objects, but hopefully I'm just
missing the code that aligns pdumper objects properly. Daniel, can you
confirm?

Let's get rid of all these alignments, and do with just GCALIGNMENT:
No LISP_ALIGNMENT, no GC_OBJECT_ALIGNMENT_MINIMUM. We'd have
GCALIGNMENT == sizeof (EMACS_INT) on all current platforms, I believe.