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 11:37:39 -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="34032"; 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 17:42:38 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 1lJIxp-0008jJ-5b for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Mar 2021 17:42:37 +0100 Original-Received: from localhost ([::1]:58350 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJIxo-0001Tw-5m for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Mar 2021 11:42:36 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40702) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJItA-0004fU-2r for emacs-devel@gnu.org; Mon, 08 Mar 2021 11:37:48 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63961) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJIt6-0000cE-Cz; Mon, 08 Mar 2021 11:37:46 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1C28C44082C; Mon, 8 Mar 2021 11:37:42 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8E0C0440900; Mon, 8 Mar 2021 11:37:40 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1615221460; bh=rlB6g43P227xUNCKne6OFHALPZr0EOetlBv9WaEyCAw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=IKO2cn765n16gCbuK6YuSlZzU/Dmbqj82S2Zi3/6sSWDMUL+zr0CfGDLJeBpKNS7X xFeQPExhHOYpDCEgjboYl3gzmwfDuXqeC6z8x/ZtxPUFIrdy1WT3rP+FQCQo6rPbdj j/t/0hq+rlx69QwGQ2Lr5fpKH2kPjcRw05dXPZt6dM/DsYkzZbXHbG1HiF1v+HH/Wg xTz4VH3v7pP1b4LuXQjQjxgNOrHTArFH1R/qUA7co1qWtyDE6WklhEg7gb6dX+MmQh 7wCEcyYTRWYuZhfbOjJ25pns7VdFYqpTjvwx1PJ34XqzK5F9NboeyqTFKnU/TXyQbZ 74ATWm84qxR0Q== Original-Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 83139120323; Mon, 8 Mar 2021 11:37:40 -0500 (EST) In-Reply-To: (Pip Cet's message of "Mon, 8 Mar 2021 16:11:26 +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:266207 Archived-At: >> 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. > I don't understand the benefits of doing that. I'm not specifically arguing for it, actually. Just pointing out that there's fair bit of design space here. I think we'd generally prefer to avoid an extra level of indirection (the marking phase tends to "kill" the cache and suffer from memory latency), so if we can compute the address of the markbit directly from the object address, it's better. > The disadvantages would be very significant: we can't free a cons > block until all its conses have been freed, and that's drastically > more likely if we increase the cons block size Fully agreed. > by a factor of 128. [ IIRC the cons blocks are currently 16KB, so it would increase it by a slightly smaller factor. Not that it matters, tho. ] > Note that 4KB pages are no longer all there is. I hear even VAX uses a > different page size ;-) Yes, we're *finally* slowly moving to slightly larger pages. >> > 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. > I agree it's a good idea to use the same approach for pdumped objects > and regular old objects, but I don't think the current pdumper > approach extends to dynamically-allocated objects, Indeed. > and I'd rather avoid searching a btree for each mark bit. That means > pdumper has to be modified to keep its objects in blocks, and those Not just pdumper. In the GC, the most important objects AFAIK are strings and vector(like)s. Vectors used to be handled fairly inefficiently, but their importance has grown, so it's worth trying to handle them very efficiently: there's even silver lining in that it would allow us to treat more of the other types as vectors (e.g. strings) and thus simplify the code. E.g. It'd be worthwhile improving our vector allocation so they get allocated in blocks of vectors of the same size.