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.devel,gmane.emacs.diffs Subject: Re: master 0fc4989: Tweak GC performance if !USE_LSB_TAG Date: Wed, 27 May 2020 06:33:49 +0000 Message-ID: References: <20200526224835.31862.49959@vcs0.savannah.gnu.org> <20200526224836.3C3F720A2C@vcs0.savannah.gnu.org> 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="69133"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Daniel Colascione , emacs-diffs@gnu.org To: emacs-devel@gnu.org, Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 27 08:35:27 2020 Return-path: Envelope-to: ged-emacs-devel@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 1jdpew-000HtA-PH for ged-emacs-devel@m.gmane-mx.org; Wed, 27 May 2020 08:35:26 +0200 Original-Received: from localhost ([::1]:37862 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdpev-0001Bt-RE for ged-emacs-devel@m.gmane-mx.org; Wed, 27 May 2020 02:35:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58722) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdpe3-0008L3-9d; Wed, 27 May 2020 02:34:31 -0400 Original-Received: from mail-ot1-x336.google.com ([2607:f8b0:4864:20::336]:43152) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jdpdz-0000sV-JK; Wed, 27 May 2020 02:34:30 -0400 Original-Received: by mail-ot1-x336.google.com with SMTP id a68so18345673otb.10; Tue, 26 May 2020 23:34:26 -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=BKR9d1GJhx/IOBVwOB4LnMynmbojM7/nPCrWg2uqt9o=; b=EZ3jcn9l1D+xKxLq8vqgyuC7XnkNq9jf2hXdXIH/YwvBjZQarrJqIyjwe0F9em5S20 1+IEiH6+/w2KCTZu5Frp/Tth2yoJ0MhbGU2RCqynn9xeV3sb40jOArbEJ4qohwtvA9gp AweOOPmpw78GPkmScgDGz/9HjO5mRzCgUzZu8FhAoHvuw4i3T0V+yWtJA/K/3l5furXl 6nSabtiTuLiPyqpf48jcOEb/4t5QFHDuY6g/ZSGGP8ztPC9Osp88jb2TLl3vlJNY+6l5 Z4M1sVD07OKuVhRJulBtr5o60Gc7FKU/5PDjyCDoE5J2aKtu8kUqfXV/arcUnjCMgvyC RS4A== 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=BKR9d1GJhx/IOBVwOB4LnMynmbojM7/nPCrWg2uqt9o=; b=Z7HXh/uu0jlS4iYz+0qhzZ7iI9JcFCpIpuERTnnXQE/9N3+yqytJpdkgq0hrNTOPsC H5JI3hQ+t8BhN/my8xdZ4yYfy6mIUwCC9NTefX3CvzNdkaEzpM/9Yf74JyY3Woji5bcE SLn9c+Lg3tTZnmR45lTmnFCV1+vJLal84Fd13NZr9Dp0bXpr4cMuBja50uEbaDDmmp9A MICAEYh9WhofEPgncvU/xVsnxD7Uh2u85vgiFAjgSfmLTc9NW2MnWLLWf8DScrA/IiJd CAHZIWmXo58ivffGIEsNnbON3gBlWbs4tumq2rWG0GDrU+03tcxMYnjT3rcrBvPvfw1B qY9A== X-Gm-Message-State: AOAM531l2fWhj23TpUYtK+YPyz/iFWOxflNMDUxmOoW2JQFH0/9vFLEP KBrUmaJ8XhkJWpaMKYc2+tujC2YUSMZqdtfi6jbacsIi X-Google-Smtp-Source: ABdhPJwwnvE/qoxkpZXI2HK4hfccQFCL1DyTYE6tFsXC1zVLKeKCKsijkbjcZ70KSHDn0sbcLd7sY46EUqoJfbr8weo= X-Received: by 2002:a9d:6a44:: with SMTP id h4mr3651390otn.287.1590561265569; Tue, 26 May 2020 23:34:25 -0700 (PDT) In-Reply-To: <20200526224836.3C3F720A2C@vcs0.savannah.gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::336; envelope-from=pipcet@gmail.com; helo=mail-ot1-x336.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-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:251498 gmane.emacs.diffs:156337 Archived-At: On Tue, May 26, 2020 at 10:48 PM Paul Eggert wrote: > branch: master > commit 0fc4989f34bdaf1bc443d05ece886ea91e7bc9cc > Author: Paul Eggert > Commit: Paul Eggert > > Tweak GC performance if !USE_LSB_TAG > > Performance issue reported by Eli Zaretskii (Bug#41321#149). > * src/alloc.c (GC_OBJECT_ALIGNMENT_MINIMUM): New constant. > (maybe_lisp_pointer): Use it instead of GCALIGNMENT. Why don't we just set GCALIGNMENT to 8/4 on those platforms? We'd waste a few bytes of pdumper space, but that's the only disadvantage I see. I don't think anyone will get the difference between GC_OBJECT_ALIGNMENT_MINIMUM and GCALIGNMENT, and the subtlety that pdumper objects are relevant to GC, but aren't aligned to GC_OBJECT_ALIGNMENT_MINIMUM. I confess I don't fully understand when pdumper.c actually aligns only to GCALIGNMENT, but I think there's a theoretical bug here: if a misaligned pdumper object is used as a key in a weak-key hash table, and the only reference to the key is on the stack, and that reference is split so we rely on mark_maybe_pointer, the hash cell entry might get collected even though it should be kept alive. I think pdumper might also be buggy on GCALIGNMENT=1 platforms that actually _require_ greater alignment than 4 for some objects, but hopefully I'm just missing the code that aligns pdumper objects properly. Daniel, can you confirm? Let's get rid of all these alignments, and do with just GCALIGNMENT: No LISP_ALIGNMENT, no GC_OBJECT_ALIGNMENT_MINIMUM. We'd have GCALIGNMENT == sizeof (EMACS_INT) on all current platforms, I believe.