From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Opportunistic GC Date: Mon, 08 Mar 2021 10:46:25 -0500 Message-ID: References: <666da624-2f59-2eb4-8e56-f0ad20dd900c@gmx.at> <26ff7447-9c29-a2f2-bf3d-9eac20a95d0f@gmx.at> <838s6xsnsv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19942"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: rudalics@gmx.at, Eli Zaretskii , emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 08 16:48:06 2021 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 1lJI74-00054q-5R for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Mar 2021 16:48:06 +0100 Original-Received: from localhost ([::1]:47694 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJI73-000357-4k for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Mar 2021 10:48:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56810) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJI5g-0001my-UJ for emacs-devel@gnu.org; Mon, 08 Mar 2021 10:46:44 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:35428) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJI5X-0001s6-68; Mon, 08 Mar 2021 10:46:40 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 81575809C7; Mon, 8 Mar 2021 10:46:28 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3314B80602; Mon, 8 Mar 2021 10:46:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1615218386; bh=pJV46b2JtgLRlk6Y3l6epVMOPq1JWb9lxUcvRlULQVM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Qy1YX0BbOEHn+YOd8LL9S4LOVytvUvierbxE+Et20pHvuS+GuDpG0icSJbWRhqd+8 Oyzd54h/gtsaD/wTwie3Zi0kGrCYod+6j+DVBUhlaMJCWt0zFH0Cj+R9dhSSatwyRK qQx2H2srNBp/eurx1CIonTQ9U5aHCiHEgLlF4VQC8u7dnwcg4PP5xhdGDkvCMn5GzP movYcu2MDdeItK2CeFy7RblWWZhixzsqgTZjOkwODesqYkCU2kXd26v9sv8ByfKUIQ y8rOwICVefNVzPldkwnjf0abvABq/UhlcwDdJrtsK0wqAYo3nQPTRQJbhhhc4+woBG sP/GsJ/ZYtSiw== Original-Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 01A821202C2; Mon, 8 Mar 2021 10:46:25 -0500 (EST) In-Reply-To: (Pip Cet's message of "Mon, 8 Mar 2021 15:02:18 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no 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:266197 Archived-At: >> Ah, so not really an easy change after all. > > For conses, it's easy. Instead of keeping the mark bits in the cons > block, we keep a pointer to the mark bits in the cons block, and > allocate the mark bits separately and (hopefully) on a different page. What you mean is that it's easy because the markbits are already separate from the cons objects (same for floats). We could also just increase the size of the cons blocks such that their markbits area takes up a whole page. That means cons blocks of about (* 16B/cons 8b/B) => 128 pages => 512KB. >> And how do you propose to keep the mark bits separately and still >> maintain coherency between the object and its bits? > Just as we do for pdumper, which already does this. In fact, I'm > pretty sure it was Daniel who said a while ago that he wants to extend > that to all GCable objects, not just those that live in the pdmp. Yes, it's a good idea to do that in general. Stefan