On Sat, May 30, 2020 at 11:31 AM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Sat, 30 May 2020 11:06:52 +0000 > > Cc: eggert@cs.ucla.edu, 41321@debbugs.gnu.org, > > Stefan Monnier > > > > > I understand that part, but my question was why, even before the > > > change in max_align_t, did we start requiring 8-byte alignment on > > > systems where that is not automatically guaranteed? > > > > I don't know. As I said, I think that was always buggy on pdumper > > systems, though the bug was very subtle. My guess is it predates > > pdumper, at which time it was a valid optimization. > > How is pdumper involved here? See the pdumper issue I described above. I can't imagine this being a significant bug, because it needs the sole surviving reference to a pdumper object to be on the stack, while simultaneously being the key in a weak-key hash table cell... > > > So this alignment requirement is only due to pthreads being used? > > > > I'm not sure what you're asking. Obviously there are systems on which > > unaligned accesses will fault or be very slow indeed, so we need to > > make sure, say, pure space allocations are aligned somehow. That > > requires a LISP_ALIGNMENT of 8. Everything beyond that is only for > > performance, pthreads, and SIMD types. > > If the system guarantees 4-byte alignment from malloc (and/or a > similar alignment of the runtime C stack), then using that doesn't > trigger problems related to unaligned accesses, right? So let me > rephrase: why isn't 4-byte alignment "good enough" for us on systems > where malloc and the runtime stack are guaranteed to be thus aligned? (The runtime stack isn't relevant, as far as I can tell, since we walk that in 4-byte steps on such systems anyway.) You're correct that on such a system, we could get away with a LISP_ALIGNMENT of 4, but a LISP_ALIGNMENT of 8 wouldn't hurt either. > > > If > > > the two 32-bit parts of the object are non-contiguous, will we be able > > > to recognize such an object, and will we be able to mark it correctly, > > > and if so, how? IOW, don't we need the upper 32-bit (which encodes > > > the object type) for the purposes of marking it? > > > > For everything but symbols, we don't, mark_maybe_pointer called on the > > low 32 bits suffices. For symbols, mark_maybe_pointer needs to be > > changed to also check the pointer at + &lispsym. > > Right, that's what I thought. So this issue also has to be fixed on > emacs-27 in order for us to provide a stable Emacs 27. I'm surprised, but glad that you think so. Patch for emacs-27 attached.