From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#46900: 28.0.50; GC uses excessive amounts of stack Date: Wed, 03 Mar 2021 18:28:23 +0200 Message-ID: <83wnuojj6g.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9776"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46900@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Mar 03 17:29:14 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1lHUN7-0002Mo-5m for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Mar 2021 17:29:13 +0100 Original-Received: from localhost ([::1]:51390 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHUN6-0005g5-8P for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Mar 2021 11:29:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45038) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHUMw-0005fF-8x for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 11:29:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45219) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lHUMv-00033N-M7 for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 11:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lHUMv-0004hY-JO for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 11:29:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Mar 2021 16:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46900 X-GNU-PR-Package: emacs Original-Received: via spool by 46900-submit@debbugs.gnu.org id=B46900.161478893518058 (code B ref 46900); Wed, 03 Mar 2021 16:29:01 +0000 Original-Received: (at 46900) by debbugs.gnu.org; 3 Mar 2021 16:28:55 +0000 Original-Received: from localhost ([127.0.0.1]:56765 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHUMp-0004hC-2d for submit@debbugs.gnu.org; Wed, 03 Mar 2021 11:28:55 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55204) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHUMn-0004h0-I6 for 46900@debbugs.gnu.org; Wed, 03 Mar 2021 11:28:53 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39221) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHUMi-0002xL-BU; Wed, 03 Mar 2021 11:28:48 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2531 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lHUMe-0007TL-Qh; Wed, 03 Mar 2021 11:28:46 -0500 In-Reply-To: (message from Pip Cet on Wed, 3 Mar 2021 15:44:33 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:201291 Archived-At: > From: Pip Cet > Date: Wed, 3 Mar 2021 15:44:33 +0000 > > Currently, GC is written to recurse when marking objects. That means > for every level of recursion that we see, a new function stack frame > is being created on the C stack; on this x86_64-pc-linux-gnu system > running Debian GNU/Linux, in an optimized build, that means 80 bytes > of stack space are reserved for each level of recursion. > > That number could be much closer to 8, which is the number of bytes of > relevant data in those 80 bytes of stack space. > > My proposal is to continue allocating the mark queue on the stack (not > the heap), but to do so in larger chunks, allocating enough space for > N objects and recursing, in the C sense, only when all N object slots > have been used. > > In addition to saving stack space, this should also help, at least, > older systems with limited return address prediction stacks. FWIW, I'm only interested in changes to GC if they bring significant gains, such as replacing the mark & sweep algorithm with something more modern and powerful. Otherwise, experience shows that messing with GC for smaller gains is not worth it: it destabilizes Emacs for no good reason, since users rarely if ever see any significant improvements. > In further patches, I'd like to change things so we no longer recurse > through symbols so enthusiastically, building up tens of thousands of > objects on the mark queue. I'd like to hear and understand the long-term plan before I agree to any such changes. And in general, I'd like to see the plan implemented in large steps, not small changes. We have bad experience with the latter: over the years there were a couple of attempts to do it that led nowhere, and we are left with their leftovers that don't make much sense on their own, and just make the sources harder to read and understand, let alone change. So please: no small changes in GC, thank you. > In the interest of full disclosure, I have several ulterior motives > for this: the WebAssembly implementation I'm using doesn't allow deep > nesting of calls; I'd like to look into parallelizing GC for which > this might be useful; and I suspect native-comp will benefit more from > further work in this area, too. If the goal is to make GC parallel, let's first discuss the idea for how to do it, and (assuming we agree to go that way) let's start with it, not present it as some long-term goal. Thanks.