From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.diffs,gmane.emacs.devel Subject: Re: master 9227864: Further fix for aborts due to GC losing pseudovectors Date: Tue, 26 May 2020 00:09:30 -0700 Organization: UCLA Computer Science Department Message-ID: References: <20200526060645.22243.34109@vcs0.savannah.gnu.org> <20200526060646.662E120A2C@vcs0.savannah.gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="116850"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: emacs-diffs@gnu.org To: Pip Cet , emacs-devel@gnu.org Original-X-From: emacs-diffs-bounces+gnu-emacs-diffs=m.gmane-mx.org@gnu.org Tue May 26 09:09:43 2020 Return-path: Envelope-to: gnu-emacs-diffs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jdTiY-000UHn-US for gnu-emacs-diffs@m.gmane-mx.org; Tue, 26 May 2020 09:09:43 +0200 Original-Received: from localhost ([::1]:54874 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdTiY-0003sA-09 for gnu-emacs-diffs@m.gmane-mx.org; Tue, 26 May 2020 03:09:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39592) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdTiT-0003rC-BW; Tue, 26 May 2020 03:09:37 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:54378) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdTiR-0002Jz-Pe; Tue, 26 May 2020 03:09:36 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 88ABB160052; Tue, 26 May 2020 00:09:32 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id hrGBuA_DIj9r; Tue, 26 May 2020 00:09:31 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 52B0C1600E0; Tue, 26 May 2020 00:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fgPW6LIhhCFO; Tue, 26 May 2020 00:09:31 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 1F34E160052; Tue, 26 May 2020 00:09:31 -0700 (PDT) Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoU In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/26 02:46:04 X-ACL-Warn: Detected OS = Linux 3.1-3.10 X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-diffs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Mailing list for Emacs changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-diffs-bounces+gnu-emacs-diffs=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-diffs" Xref: news.gmane.io gmane.emacs.diffs:156309 gmane.emacs.devel:251432 Archived-At: 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.