From: Paul Eggert <eggert@cs.ucla.edu>
To: Pip Cet <pipcet@gmail.com>, emacs-devel@gnu.org
Cc: emacs-diffs@gnu.org
Subject: Re: master 9227864: Further fix for aborts due to GC losing pseudovectors
Date: Tue, 26 May 2020 00:09:30 -0700 [thread overview]
Message-ID: <db3fac52-7758-134c-bce6-b757a9fff935@cs.ucla.edu> (raw)
In-Reply-To: <CAOqdjBddeH2iHW2m2T+U+FALyKEwbP_aZrLYDnjUoX8=Ukc9qw@mail.gmail.com>
On 5/25/20 11:40 PM, Pip Cet wrote:
> It makes the code much more
> complicated, all for hypothetical systems that require alignment > 8
> for a hypothetical 16-byte data type in a Lisp structure.
It's true that we haven't run into these systems yet. However, I worry that it
won't be all that hypothetical in the not-so-distant future, given that so many
SIMD instructions require multiple-of-16 alignment and Emacs pseudovectors use
system types that may require such alignment.
> I think we should be specific here and say it's the mingw.org 32-bit
> version (or whatever Eli's using) only that has problems.
It can also happen with GCC 7 + glibc 2.25. Some platforms are fitfully moving
to alignment-of-16 malloc and there are mismatches between system pieces. I'm
not sure we can catalog all the affected systems.
>> - generate better code.
>> + generate better code. Also, such structs should be added to the
>> + emacs_align_type union.
>
> That's going to be a maintenance nightmare, since failures to do so
> won't actually show up on real machines, and a lot of wasted memory if
> someone does add an AVX512 type.
In current master I've fixed this so that there is zero wasted memory; the type
is used only to calculate alignment, not to allocate memory.
It is a maintenance hassle, though not bad compared to the hassle of remembering
to add GCALIGNED_STRUCT and GCALIGNED_UNION_MEMBER all over the place, which we
have to do anyway.
> I'd prefer a simple warning not to use long double or similarly
> unusual types in pseudovectors, and an eassert (see below) to catch it
> if people do that.
That's not going to work if some platform uses an alignment-of-16 type in
pthread_cond_t (or some other system type that Emacs uses).
> I think a simple eassert (GCALIGNMENT % alignof (type) == 0) in an
> (inlined, obviously) version of allocate_pseudovector should suffice
> to catch this hypothetical problem.
I assume you meant 'verify' rather than 'eassert'? That'd catch the bug at
compile time.
But instead, how about an alignment argument to allocate_pseudovector, or a
variant of allocate_pseudovector that takes such an argument? Then Emacs could
support any alignment-greater-than-16 types that turn up.
next prev parent reply other threads:[~2020-05-26 7:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200526060645.22243.34109@vcs0.savannah.gnu.org>
[not found] ` <20200526060646.662E120A2C@vcs0.savannah.gnu.org>
2020-05-26 6:40 ` master 9227864: Further fix for aborts due to GC losing pseudovectors Pip Cet
2020-05-26 7:09 ` Paul Eggert [this message]
2020-05-26 7:25 ` Pip Cet
2020-05-26 7:40 ` Paul Eggert
2020-05-26 8:02 ` Pip Cet
2020-05-26 14:51 ` Stefan Monnier
2020-05-26 17:25 ` Pip Cet
2020-05-26 17:46 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=db3fac52-7758-134c-bce6-b757a9fff935@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
--cc=emacs-diffs@gnu.org \
--cc=pipcet@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).