From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Pip Cet 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 17:25:38 +0000 Message-ID: References: <20200526060645.22243.34109@vcs0.savannah.gnu.org> <20200526060646.662E120A2C@vcs0.savannah.gnu.org> <26b54430-b654-3e13-8e3c-2f4482af60e1@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="121511"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Paul Eggert , emacs-diffs@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-diffs-bounces+gnu-emacs-diffs=m.gmane-mx.org@gnu.org Tue May 26 19:27:25 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 1jddMJ-000VQy-FP for gnu-emacs-diffs@m.gmane-mx.org; Tue, 26 May 2020 19:27:23 +0200 Original-Received: from localhost ([::1]:33962 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jddMI-0004QC-AU for gnu-emacs-diffs@m.gmane-mx.org; Tue, 26 May 2020 13:27:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60110) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jddLG-0002kw-7d; Tue, 26 May 2020 13:26:18 -0400 Original-Received: from mail-oo1-xc2c.google.com ([2607:f8b0:4864:20::c2c]:34040) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jddLF-0005gY-7R; Tue, 26 May 2020 13:26:17 -0400 Original-Received: by mail-oo1-xc2c.google.com with SMTP id s139so4423207oos.1; Tue, 26 May 2020 10:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MEynTx3bkJYn1TApPedN6nTPXgFVbokf6MCiaLCXLuA=; b=Ao8L1kRccinR0zZHwGBAWZk3MtVhGEIrJkj1BsSWikxXtFpN86x9OwIqWNQbXwNBs9 M0iuN/Q2FniD6nwcpozbbwaGusAxwCXSG2hYOzi20khkYx72qLjkxdpUSc2iRUnj1zBS G5QHOofByNlH3GzIt3L6KvXHtNGpY/g6ErgELe2U7PGfp9NK1+2jdOXBHgCjqjtPBSWx ooqPI19yyE/C9I6TVkTBhfUqbYNezQgIP2uD8yxXsIiDjTV4dL2J5FgIadV9G5iGUdKE TsTQN94/hquDzUPv5CtRjgMjmVeWoS3MnACfEfY+H4zyle0ukAZt9MWjA4qCmVD7UguK GFMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MEynTx3bkJYn1TApPedN6nTPXgFVbokf6MCiaLCXLuA=; b=H/Decdg2wokHKXnUN+KC42i283bk79BFF7YMMSfzr+2DW6PExmaqRTNDKgBVs5pDwv tdaeIWXN2XiE8R9t5vchcLbTrDQVLPuINUPJZ7mwox5ZNpCWtzE0dbytutBblzEFTa4k mZ/bAPpgFUYp0Osust1v5CEMKeWrkwhxc/aWrAnkR4HzizmYTXkYu7srtrosGCSeVzBr 86RMGO85NK4Ls6Z9VWWUVl7FXW+A4bOzpfulsyFsl320QT14aUNLY7Et7Gi6J7IWRhqB TfNsMzJvs5pEaYA5uqPgZXIRxwwEiTgFK2sPgNKH0SjtFrAxjsfs/pbl1i5/WQhvOVAx HiDA== X-Gm-Message-State: AOAM531JbFq/+EPu0zHWbnxZWD9SOSY4EmJnYAawgaYUotq/cWtoeHcN VFxremZ969MeB6tP1Zxwd5qDaOmvG8MwDLhvHLA= X-Google-Smtp-Source: ABdhPJwKof5eEM4apgXG1o9s/8nDMdF1lJBEUXURyt1s3NKXlD5nlnwhJIQK/nvZWJghOju05kUtq1t2FfWdKPw4rjw= X-Received: by 2002:a4a:e702:: with SMTP id y2mr17644126oou.44.1590513974628; Tue, 26 May 2020 10:26:14 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::c2c; envelope-from=pipcet@gmail.com; helo=mail-oo1-xc2c.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:156333 gmane.emacs.devel:251466 Archived-At: On Tue, May 26, 2020 at 2:51 PM Stefan Monnier wrote: > > Oh, you're right. No harm so far since LISP_ALIGNMENT is 8 on current platforms. > > For 64bit float, a LISP_ALIGNMENT greater than 8 would imply > a significant amount of waste (same for cons cells on 32bit systems). > So I think it'll stay at 8 for the foreseeable future (which doesn't > mean we can't decide to use large alignment for some other objects, of > course). I'm hoping that if we have an allocate_aligned_pseudovector function (or macro) we won't need LISP_ALIGNMENT at all. Which is good, since it was misnamed (pure Lisp data and Lisp data on the stack never obeyed LISP_ALIGNMENT. I'm suspicious about pdumper data, too, as pdumper.c sets DUMP_ALIGNMENT to GCALIGNMENT on many practical platforms, not LISP_ALIGNMENT). It's true that GCALIGNMENT is 1 on some platforms, but we can change that, can't we? I guess the recent bugs also make it impossible to do a 32-bit --wide-int USE_LSB_TAG build. My suspicion is that that would actually be faster, since we need only look at one 32-bit word to chase a pointer, but it would make stack marking a lot slower...