unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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.



  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).