From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#46900: 28.0.50; GC uses excessive amounts of stack Date: Wed, 3 Mar 2021 15:44:33 +0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3604"; mail-complaints-to="usenet@ciao.gmane.io" To: 46900@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Mar 03 16:46:17 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 1lHThV-0000gd-V9 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Mar 2021 16:46:13 +0100 Original-Received: from localhost ([::1]:55416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHThU-0004dG-U7 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Mar 2021 10:46:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56286) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHThL-0004ah-6M for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 10:46:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45157) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lHThK-00050Y-6N for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 10:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lHThK-0003Yb-3v for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 10:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Mar 2021 15:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 46900 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.161478631613606 (code B ref -1); Wed, 03 Mar 2021 15:46:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 3 Mar 2021 15:45:16 +0000 Original-Received: from localhost ([127.0.0.1]:56703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHTgZ-0003XO-SO for submit@debbugs.gnu.org; Wed, 03 Mar 2021 10:45:16 -0500 Original-Received: from lists.gnu.org ([209.51.188.17]:56664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHTgY-0003XE-Bt for submit@debbugs.gnu.org; Wed, 03 Mar 2021 10:45:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56080) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHTgY-0004NL-0R for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 10:45:14 -0500 Original-Received: from mail-ot1-x32f.google.com ([2607:f8b0:4864:20::32f]:37423) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lHTgV-0004Yr-Jv for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 10:45:13 -0500 Original-Received: by mail-ot1-x32f.google.com with SMTP id g8so20320473otk.4 for ; Wed, 03 Mar 2021 07:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=c8HDNcrNoz99riKRwZ9iDxJxDCXP/emUDlwxdB/pJgI=; b=ulhrRuiIgjT3hsKT7Flwum0aFsf1zcpnOUpHMBrNJ/RGJUYwsQkJtn4FRVsBRIdKfv 7IzMBzylXSA25I6eH7odwndr1fCexUwjGoU0BklCFdLnHbP+Zake/93kphpGqT8qh2S6 Aat9OuG1T7bNChF/HMV6keIz8D18QT2NSvtYSCqBfd2Jko/MWsf23NWErkfcRKxOEZtx oetrG8Jp1KsBkIkh8GXLUHWeldag3Ir875gv0eH9VgINR22DgSlrbWdkoSiW84ALHlTJ 6oQCuqDAiBhVwJvipABWow00E6o2epLnpDdmPB5N1Rb+q4L79ivyfXNdYrWNvFphoPxF Zm8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=c8HDNcrNoz99riKRwZ9iDxJxDCXP/emUDlwxdB/pJgI=; b=gMHUQcoVRLQ7pRydG/WESkL8tBZv81ic+zct15OZoyrvVf23reVAEWEJIeGN7N/aeN m3lhA9i3M+JX1/7w3ztcce/OgO0gKPOLvthgqxOLSSAqgeqBloyqR5mz1jKQTEWOa4/q sDH4Q2Bc3NSL8EANmElfqtExgKTk2BZYY5bxDo2Ehp9ExwzMy7uZQZsuii6+p2cFbyiB HxE33oGhJIqKCy9r+gQIBOnlgOO4WkbzigHDekkgQzJOoG/WM4xIYm6ehtswLbZZJi9a Ec/Q4DUoDqsLivBn5qgFi4rVl1QJJRAfOs7adh+/b4COEB0z3+NwjR6l6xASIA683/x2 /V/w== X-Gm-Message-State: AOAM530urqDehUInSVVxRtt8lsRP5ihVUUsjcAKIpcQl83Qivj3zd1sF jfO9eJIYUA2687AUwQpjCdRlngoSMBKdqn29sw/C+aRFCwQ= X-Google-Smtp-Source: ABdhPJyOdlV+WgPOPhwWzuZblJvzXx6iFdUHNQqFUC9MN+RPPYtKJmwwfC6djcppH5MQ6MOXEPGrnF0nqUCoaZd6sGw= X-Received: by 2002:a9d:131:: with SMTP id 46mr22646587otu.287.1614786309232; Wed, 03 Mar 2021 07:45:09 -0800 (PST) Received-SPF: pass client-ip=2607:f8b0:4864:20::32f; envelope-from=pipcet@gmail.com; helo=mail-ot1-x32f.google.com 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_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:201286 Archived-At: This is a long-standing issue. 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. IMHO, it would also help, not hinder, debugging of GC internals, as more context would be available in the function frame. Indeed, the patch I will send once this has a bug number keeps all of the large "soft" stack frames in a linked list so we can easily walk them. 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. 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.