From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Joseph Mingrone Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Aug 2019 12:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 37006@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.156552721412084 (code B ref -1); Sun, 11 Aug 2019 12:41:01 +0000 Received: (at submit) by debbugs.gnu.org; 11 Aug 2019 12:40:14 +0000 Received: from localhost ([127.0.0.1]:44818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwn8v-00038p-Em for submit@debbugs.gnu.org; Sun, 11 Aug 2019 08:40:14 -0400 Received: from lists.gnu.org ([209.51.188.17]:57077) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwn8s-00038c-Bl for submit@debbugs.gnu.org; Sun, 11 Aug 2019 08:40:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60864) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hwn8p-0007o6-FZ for bug-gnu-emacs@gnu.org; Sun, 11 Aug 2019 08:40:10 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hwn8m-0000ZK-By for bug-gnu-emacs@gnu.org; Sun, 11 Aug 2019 08:40:07 -0400 Received: from mail-qt1-x82c.google.com ([2607:f8b0:4864:20::82c]:36717) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hwn8m-0000YT-1k for bug-gnu-emacs@gnu.org; Sun, 11 Aug 2019 08:40:04 -0400 Received: by mail-qt1-x82c.google.com with SMTP id z4so100364117qtc.3 for ; Sun, 11 Aug 2019 05:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftfl.ca; s=google; h=from:to:subject:date:message-id:user-agent:mime-version; bh=fkNShc/A5RRDO8PJbUZW0PSwMjhympNgLFXJcy8igzI=; b=ByhJltx/u0wd+tHtFYBlF33C4VlFt9S5/xgjOF4+b27uZZpPlt4UHMMpp+Xc7r8xYX voyHEBJC8XmubI2PmmlvltMmVuI73EwI4AUTtimoUfi8UzJVEyaNGg8+VaRmNXsSXR9b xQawIxucAmmg/8Ni+3o2v6RIPuFy/XLz/Xk9Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version; bh=fkNShc/A5RRDO8PJbUZW0PSwMjhympNgLFXJcy8igzI=; b=a9q1/B3uqDrHs5A6Bn2wQ6aw+K8qVTCpLahApdai+0hfTyOlCqNacB20/EeCz1c2/n qYHNIMjp+N4FUHx1OclNPqh+Z0BxQ7SI8a4GiUBqQ7R+91ElLfijrR5YEjHQeE05BWqf 4t++RzffhDIWN3oFlkhNnVlUOmuOpxdi9abBGGJbZIzEgx3WxhXI+s/dQ/NqWAQIhjy5 n07l2HtKcf6K62GZiOUyg0BrNnZVhYpwztl7Rv5GEXy4oDAahan6i7T6GRiEdCRZBin0 /Bp8zlhJcWJFjMrb8iaGwlYSGFQffcs0Sojm63UxbYeEipib7VwNW6z+afqNslPRjQxD WNcQ== X-Gm-Message-State: APjAAAU+h0C9Xn3tnzeU71wtj6yTkoUC5ZR51RsMldklzhB7n4pzJCwK FLj0d8vks3b3D1g1JEvr12TbWf+PME0= X-Google-Smtp-Source: APXvYqxS1EhL3mQPLPjlWZPRm2eHwUqReOR2BpQXtDWNGGbQkGxLGENe4VtXEWkIMqd5a/9bjTb6AA== X-Received: by 2002:ac8:2535:: with SMTP id 50mr25702940qtm.373.1565527201535; Sun, 11 Aug 2019 05:40:01 -0700 (PDT) Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-142-167-140-18.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.167.140.18]) by smtp.gmail.com with ESMTPSA id f12sm3795389qkm.18.2019.08.11.05.40.00 for (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sun, 11 Aug 2019 05:40:00 -0700 (PDT) From: Joseph Mingrone Date: Sun, 11 Aug 2019 09:39:58 -0300 Message-ID: <86pnlbooyp.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::82c X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) After 26de2d42 from 2019-06-20, garbage collection is not happening and allocated memory continues to grow until Aug 10 21:39:02 phe kernel: pid 73800 (emacs-27.0.50), uid 1001, was killed: out of swap space and Aug 10 21:39:07 phe kernel: swap_pager_getswapspace(3): failed In GNU Emacs 27.0.50 (build 1, amd64-portbld-freebsd12.0, GTK+ Version 3.24.10) Windowing system distributor 'The X.Org Foundation', version 11.0.11804000 System Description: 12.0-RELEASE-p9 Configured using: 'configure --disable-build-details --localstatedir=/var --with-x --enable-acl --without-cairo --without-dbus --without-gconf --with-gif --with-gnutls --without-gsettings --with-x-toolkit=gtk3 --without-harfbuzz --with-jpeg --with-json --with-file-notification=kqueue --with-lcms2 --with-m17n-flt --with-imagemagick --with-mailutils --with-modules --with-sound=oss --with-libotf --with-png --with-toolkit-scroll-bars --with-rsvg --with-threads --with-tiff --with-xft --with-xim --with-xml2 --with-xpm --without-xwidgets --x-libraries=/usr/local/lib --x-includes=/usr/local/include --prefix=/usr/local --mandir=/usr/local/man --disable-silent-rules --infodir=/usr/local/share/emacs/info/ --build=amd64-portbld-freebsd12.0 'CFLAGS=-O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'CPPFLAGS=-isystem /usr/local/include' 'LDFLAGS= -fstack-protector-strong -L/usr/local/lib '' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GLIB NOTIFY KQUEUE ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS JSON PDUMPER LCMS2 GMP Important settings: value of $LANG: en_CA.UTF-8 locale-coding-system: utf-8-unix Major mode: Message Minor modes in effect: gnus-message-citation-mode: t erc-spelling-mode: t erc-ring-mode: t erc-networks-mode: t erc-netsplit-mode: t erc-menu-mode: t erc-log-mode: t erc-list-mode: t erc-pcomplete-mode: t erc-button-mode: t erc-stamp-mode: t erc-autojoin-mode: t erc-track-mode: t erc-track-minor-mode: t erc-match-mode: t erc-irccontrols-mode: t erc-noncommands-mode: t erc-move-to-prompt-mode: t erc-readonly-mode: t mml-mode: t shell-dirtrack-mode: t flyspell-mode: t global-undo-tree-mode: t undo-tree-mode: t which-key-mode: t show-paren-mode: t savehist-mode: t global-company-mode: t company-mode: t global-auto-revert-mode: t counsel-mode: t ivy-mode: t cl-old-struct-compat-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t visual-line-mode: t transient-mark-mode: t abbrev-mode: t Load-path shadows: /home/jrm/.emacs.d/elpa/slime-20190724.1352/slime-autoloads hides /usr/local/share/emacs/27.0.50/site-lisp/slime/slime-autoloads /home/jrm/.emacs.d/elpa/slime-20190724.1352/slime hides /usr/local/share/emacs/27.0.50/site-lisp/slime/slime /home/jrm/.emacs.d/elpa/slime-20190724.1352/slime-tests hides /usr/local/share/emacs/27.0.50/site-lisp/slime/slime-tests /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-org hides /usr/local/share/emacs/27.0.50/lisp/org/ox-org /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-bibtex hides /usr/local/share/emacs/27.0.50/lisp/org/org-bibtex /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ruby hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ruby /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-table hides /usr/local/share/emacs/27.0.50/lisp/org/ob-table /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-awk hides /usr/local/share/emacs/27.0.50/lisp/org/ob-awk /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-element hides /usr/local/share/emacs/27.0.50/lisp/org/org-element /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ref hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ref /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-processing hides /usr/local/share/emacs/27.0.50/lisp/org/ob-processing /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ditaa hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ditaa /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-info hides /usr/local/share/emacs/27.0.50/lisp/org/org-info /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-md hides /usr/local/share/emacs/27.0.50/lisp/org/ox-md /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-colview hides /usr/local/share/emacs/27.0.50/lisp/org/org-colview /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-mhe hides /usr/local/share/emacs/27.0.50/lisp/org/org-mhe /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-python hides /usr/local/share/emacs/27.0.50/lisp/org/ob-python /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-shell hides /usr/local/share/emacs/27.0.50/lisp/org/ob-shell /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-ascii hides /usr/local/share/emacs/27.0.50/lisp/org/ox-ascii /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-lisp hides /usr/local/share/emacs/27.0.50/lisp/org/ob-lisp /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-capture hides /usr/local/share/emacs/27.0.50/lisp/org/org-capture /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-js hides /usr/local/share/emacs/27.0.50/lisp/org/ob-js /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-src hides /usr/local/share/emacs/27.0.50/lisp/org/org-src /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-sass hides /usr/local/share/emacs/27.0.50/lisp/org/ob-sass /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-footnote hides /usr/local/share/emacs/27.0.50/lisp/org/org-footnote /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-lob hides /usr/local/share/emacs/27.0.50/lisp/org/ob-lob /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-gnus hides /usr/local/share/emacs/27.0.50/lisp/org/org-gnus /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-picolisp hides /usr/local/share/emacs/27.0.50/lisp/org/ob-picolisp /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-scheme hides /usr/local/share/emacs/27.0.50/lisp/org/ob-scheme /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-mobile hides /usr/local/share/emacs/27.0.50/lisp/org/org-mobile /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-latex hides /usr/local/share/emacs/27.0.50/lisp/org/ob-latex /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-crypt hides /usr/local/share/emacs/27.0.50/lisp/org/org-crypt /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-docview hides /usr/local/share/emacs/27.0.50/lisp/org/org-docview /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob hides /usr/local/share/emacs/27.0.50/lisp/org/ob /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-icalendar hides /usr/local/share/emacs/27.0.50/lisp/org/ox-icalendar /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-rmail hides /usr/local/share/emacs/27.0.50/lisp/org/org-rmail /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-publish hides /usr/local/share/emacs/27.0.50/lisp/org/ox-publish /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-sed hides /usr/local/share/emacs/27.0.50/lisp/org/ob-sed /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-datetree hides /usr/local/share/emacs/27.0.50/lisp/org/org-datetree /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-protocol hides /usr/local/share/emacs/27.0.50/lisp/org/org-protocol /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-matlab hides /usr/local/share/emacs/27.0.50/lisp/org/ob-matlab /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-inlinetask hides /usr/local/share/emacs/27.0.50/lisp/org/org-inlinetask /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-shen hides /usr/local/share/emacs/27.0.50/lisp/org/ob-shen /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-core hides /usr/local/share/emacs/27.0.50/lisp/org/ob-core /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-entities hides /usr/local/share/emacs/27.0.50/lisp/org/org-entities /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ebnf hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ebnf /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-coq hides /usr/local/share/emacs/27.0.50/lisp/org/ob-coq /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-forth hides /usr/local/share/emacs/27.0.50/lisp/org/ob-forth /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox hides /usr/local/share/emacs/27.0.50/lisp/org/ox /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-hledger hides /usr/local/share/emacs/27.0.50/lisp/org/ob-hledger /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-abc hides /usr/local/share/emacs/27.0.50/lisp/org/ob-abc /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org hides /usr/local/share/emacs/27.0.50/lisp/org/org /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-archive hides /usr/local/share/emacs/27.0.50/lisp/org/org-archive /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-J hides /usr/local/share/emacs/27.0.50/lisp/org/ob-J /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-macs hides /usr/local/share/emacs/27.0.50/lisp/org/org-macs /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-version hides /usr/local/share/emacs/27.0.50/lisp/org/org-version /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-exp hides /usr/local/share/emacs/27.0.50/lisp/org/ob-exp /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-ctags hides /usr/local/share/emacs/27.0.50/lisp/org/org-ctags /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-java hides /usr/local/share/emacs/27.0.50/lisp/org/ob-java /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-sql hides /usr/local/share/emacs/27.0.50/lisp/org/ob-sql /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-lint hides /usr/local/share/emacs/27.0.50/lisp/org/org-lint /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-keys hides /usr/local/share/emacs/27.0.50/lisp/org/ob-keys /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-eshell hides /usr/local/share/emacs/27.0.50/lisp/org/org-eshell /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-plantuml hides /usr/local/share/emacs/27.0.50/lisp/org/ob-plantuml /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ocaml hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ocaml /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-sqlite hides /usr/local/share/emacs/27.0.50/lisp/org/ob-sqlite /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-list hides /usr/local/share/emacs/27.0.50/lisp/org/org-list /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-lua hides /usr/local/share/emacs/27.0.50/lisp/org/ob-lua /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-C hides /usr/local/share/emacs/27.0.50/lisp/org/ob-C /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-habit hides /usr/local/share/emacs/27.0.50/lisp/org/org-habit /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-bbdb hides /usr/local/share/emacs/27.0.50/lisp/org/org-bbdb /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-lilypond hides /usr/local/share/emacs/27.0.50/lisp/org/ob-lilypond /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-latex hides /usr/local/share/emacs/27.0.50/lisp/org/ox-latex /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-asymptote hides /usr/local/share/emacs/27.0.50/lisp/org/ob-asymptote /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-groovy hides /usr/local/share/emacs/27.0.50/lisp/org/ob-groovy /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-screen hides /usr/local/share/emacs/27.0.50/lisp/org/ob-screen /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-org hides /usr/local/share/emacs/27.0.50/lisp/org/ob-org /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-eww hides /usr/local/share/emacs/27.0.50/lisp/org/org-eww /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-octave hides /usr/local/share/emacs/27.0.50/lisp/org/ob-octave /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-vala hides /usr/local/share/emacs/27.0.50/lisp/org/ob-vala /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-indent hides /usr/local/share/emacs/27.0.50/lisp/org/org-indent /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-macro hides /usr/local/share/emacs/27.0.50/lisp/org/org-macro /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-gnuplot hides /usr/local/share/emacs/27.0.50/lisp/org/ob-gnuplot /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-haskell hides /usr/local/share/emacs/27.0.50/lisp/org/ob-haskell /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-dot hides /usr/local/share/emacs/27.0.50/lisp/org/ob-dot /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-html hides /usr/local/share/emacs/27.0.50/lisp/org/ox-html /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-calc hides /usr/local/share/emacs/27.0.50/lisp/org/ob-calc /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-fortran hides /usr/local/share/emacs/27.0.50/lisp/org/ob-fortran /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-stan hides /usr/local/share/emacs/27.0.50/lisp/org/ob-stan /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ledger hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ledger /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-io hides /usr/local/share/emacs/27.0.50/lisp/org/ob-io /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-install hides /usr/local/share/emacs/27.0.50/lisp/org/org-install /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-clock hides /usr/local/share/emacs/27.0.50/lisp/org/org-clock /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-agenda hides /usr/local/share/emacs/27.0.50/lisp/org/org-agenda /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-table hides /usr/local/share/emacs/27.0.50/lisp/org/org-table /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-attach hides /usr/local/share/emacs/27.0.50/lisp/org/org-attach /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-faces hides /usr/local/share/emacs/27.0.50/lisp/org/org-faces /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-beamer hides /usr/local/share/emacs/27.0.50/lisp/org/ox-beamer /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-comint hides /usr/local/share/emacs/27.0.50/lisp/org/ob-comint /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-mscgen hides /usr/local/share/emacs/27.0.50/lisp/org/ob-mscgen /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-w3m hides /usr/local/share/emacs/27.0.50/lisp/org/org-w3m /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-maxima hides /usr/local/share/emacs/27.0.50/lisp/org/ob-maxima /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-css hides /usr/local/share/emacs/27.0.50/lisp/org/ob-css /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-compat hides /usr/local/share/emacs/27.0.50/lisp/org/org-compat /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-feed hides /usr/local/share/emacs/27.0.50/lisp/org/org-feed /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-irc hides /usr/local/share/emacs/27.0.50/lisp/org/org-irc /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-clojure hides /usr/local/share/emacs/27.0.50/lisp/org/ob-clojure /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-odt hides /usr/local/share/emacs/27.0.50/lisp/org/ox-odt /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-man hides /usr/local/share/emacs/27.0.50/lisp/org/ox-man /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-emacs-lisp hides /usr/local/share/emacs/27.0.50/lisp/org/ob-emacs-lisp /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-tangle hides /usr/local/share/emacs/27.0.50/lisp/org/ob-tangle /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-R hides /usr/local/share/emacs/27.0.50/lisp/org/ob-R /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-makefile hides /usr/local/share/emacs/27.0.50/lisp/org/ob-makefile /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-duration hides /usr/local/share/emacs/27.0.50/lisp/org/org-duration /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-texinfo hides /usr/local/share/emacs/27.0.50/lisp/org/ox-texinfo /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-id hides /usr/local/share/emacs/27.0.50/lisp/org/org-id /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-eval hides /usr/local/share/emacs/27.0.50/lisp/org/ob-eval /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-timer hides /usr/local/share/emacs/27.0.50/lisp/org/org-timer /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-mouse hides /usr/local/share/emacs/27.0.50/lisp/org/org-mouse /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-pcomplete hides /usr/local/share/emacs/27.0.50/lisp/org/org-pcomplete /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-loaddefs hides /usr/local/share/emacs/27.0.50/lisp/org/org-loaddefs /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-plot hides /usr/local/share/emacs/27.0.50/lisp/org/org-plot /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-perl hides /usr/local/share/emacs/27.0.50/lisp/org/ob-perl /home/jrm/.emacs.d/elpa/let-alist-1.0.6/let-alist hides /usr/local/share/emacs/27.0.50/lisp/emacs-lisp/let-alist Features: (shadow emacsbug bbdb-message sendmail nnir bbdb-mua bbdb-com crm sort gnus-cite mail-extr gnus-async gnus-bcklg qp gnus-ml disp-table ace-window cl-print help-fns radix-tree make-mode tramp-cache tramp-sh bookmark mm-archive mule-util url-http url-gw url-cache url-auth url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util finder-inf gnutls network-stream nsm erc-spelling erc-ring erc-networks erc-netsplit erc-menu erc-log erc-list erc-pcomplete erc-button erc-fill erc-stamp erc-join znc warnings erc-track erc-match erc-tex easy-mmode erc-goodies erc erc-backend erc-compat pp erc-loaddefs cl hl-line gnus-topic nndraft nnmh nnagent nnml gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig mailcap nntp gnus-cache gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message rmc puny rfc822 mml mml-sec epa derived epg mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader gnus-win gnus nnheader wid-edit gnus-util rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils text-property-search time-date tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat shell pcomplete parse-time ls-lisp format-spec rx server flyspell ispell undo-tree diff smart-mode-line-dark-theme smart-mode-line rich-minority s pdf-tools-loaddefs misc hydra lv ace-link avy bbdb bbdb-site timezone company-oddmuse company-keywords company-etags etags fileloop generator company-gtags company-dabbrev-code company-dabbrev company-files company-capf company-cmake company-xcode company-clang company-semantic company-eclim company-template company-bbdb which-key paren savehist company edmacro kmacro pcase autorevert filenotify counsel xdg xref project dired dired-loaddefs compile comint ansi-color swiper cl-extra help-mode ivy delsel ring colir color ivy-overlay ffap thingatpt cus-start cus-load benchmark-init benchmark-init-loaddefs tex-site advice slime-autoloads info package easymenu epg-config url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads kqueue lcms2 dynamic-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 4672710 1249112) (symbols 48 33763 2) (strings 32 177500 153301) (string-bytes 1 6559318) (vectors 16 108474) (vector-slots 8 4931122 2331820) (floats 8 565 3210) (intervals 56 12670 13121) (buffers 992 90)) <#secure method=pgpmime mode=sign> From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Aug 2019 15:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Joseph Mingrone Cc: 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156553641328130 (code B ref 37006); Sun, 11 Aug 2019 15:14:01 +0000 Received: (at 37006) by debbugs.gnu.org; 11 Aug 2019 15:13:33 +0000 Received: from localhost ([127.0.0.1]:45704 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwpXJ-0007Je-Ju for submit@debbugs.gnu.org; Sun, 11 Aug 2019 11:13:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33828) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwpXG-0007JP-G7 for 37006@debbugs.gnu.org; Sun, 11 Aug 2019 11:13:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hwpXB-0000GE-9G; Sun, 11 Aug 2019 11:13:25 -0400 Received: from [176.228.60.248] (port=2786 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hwpXA-0003Rv-Fw; Sun, 11 Aug 2019 11:13:25 -0400 Date: Sun, 11 Aug 2019 18:13:07 +0300 Message-Id: <83k1bju458.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <86pnlbooyp.fsf@phe.ftfl.ca> (message from Joseph Mingrone on Sun, 11 Aug 2019 09:39:58 -0300) References: <86pnlbooyp.fsf@phe.ftfl.ca> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Joseph Mingrone > Date: Sun, 11 Aug 2019 09:39:58 -0300 > > After 26de2d42 from 2019-06-20, garbage collection is not happening and > allocated memory continues to grow until > > Aug 10 21:39:02 phe kernel: pid 73800 (emacs-27.0.50), uid > 1001, was killed: out of swap space > > and > > Aug 10 21:39:07 phe kernel: swap_pager_getswapspace(3): > failed I see this on GNU/Linux, but not on MS-Windows, FWIW. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 11 12:20:12 2019 Received: (at control) by debbugs.gnu.org; 11 Aug 2019 16:20:12 +0000 Received: from localhost ([127.0.0.1]:45731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwqZo-0000Ov-Jk for submit@debbugs.gnu.org; Sun, 11 Aug 2019 12:20:12 -0400 Received: from mail152c50.megamailservers.eu ([91.136.10.162]:44586 helo=mail50c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwqZm-0000Om-OM for control@debbugs.gnu.org; Sun, 11 Aug 2019 12:20:11 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1565540409; bh=AGdkg7ATrIlytXUjgpuerlqMc8aiK9POIkfB1eq/9bM=; h=From:Subject:Date:To:From; b=SHbTeEpXHOXt2z/K82aVynjxM1TzmIdQHkUkxQKXfGh1L9vUSsEqUP+2RHfc0deso rBcZQFyL/miyGeyKKUGLLeVIuH4Lq8WC2ALcKn711z9wQUPejIdjRPRZV4FoLw4oGb d3a6f1VVMkTF/RBjBT8Zoac2mJ04SyQ/RQLKOOzM= Feedback-ID: mattiase@acm.or Received: from [192.168.0.4] ([188.150.171.71]) (authenticated bits=0) by mail50c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id x7BGK7iY007494 for ; Sun, 11 Aug 2019 16:20:09 +0000 From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: ctrl Message-Id: Date: Sun, 11 Aug 2019 18:20:07 +0200 To: control@debbugs.gnu.org X-Mailer: Apple Mail (2.3445.104.11) X-CTCH-RefID: str=0001.0A0B020B.5D504039.000F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=CNcEoyjD c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=E3glv-CrpjZUFXN6wHkA:9 a=CjuIK1q_8ugA:10 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) tags 37006 patch quit From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Aug 2019 16:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: jrm@ftfl.ca Cc: Eli Zaretskii , Paul Eggert , 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.15655406231903 (code B ref 37006); Sun, 11 Aug 2019 16:24:01 +0000 Received: (at 37006) by debbugs.gnu.org; 11 Aug 2019 16:23:43 +0000 Received: from localhost ([127.0.0.1]:45736 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwqdD-0000Ud-52 for submit@debbugs.gnu.org; Sun, 11 Aug 2019 12:23:43 -0400 Received: from mail156c50.megamailservers.eu ([91.136.10.166]:46262 helo=mail51c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwqdB-0000UV-N1 for 37006@debbugs.gnu.org; Sun, 11 Aug 2019 12:23:42 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1565540611; bh=8lBi61DL1i2QCkL+4PbqXBm9yFM3/3IKMkfdPftxsSQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=SFzWWBnhLOi50gecypJJQFHKuEckQiI+p6LxNVPXXG0UvOxvA0np33bWJMA7cmluH TSriDbwu8qwSSATyKdqNPAk0JqylmNUG4jI1ODr0ucUzk733XCl1IRJHd+Uu8jtvCp s9J5iN+S2jMK9fcVNj9VJt3nFuYjVcQL7ibO1vnY= Feedback-ID: mattiase@acm.or Received: from [192.168.0.4] ([188.150.171.71]) (authenticated bits=0) by mail51c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id x7BGNTAJ018346; Sun, 11 Aug 2019 16:23:30 +0000 From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Message-Id: <24BB9DB5-D832-462F-A03C-5595A80B6973@acm.org> Content-Type: multipart/mixed; boundary="Apple-Mail=_D6DABFC1-0A66-4D5C-82F0-60D31AF39C10" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 11 Aug 2019 18:23:28 +0200 In-Reply-To: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> X-Mailer: Apple Mail (2.3445.104.11) X-CTCH-RefID: str=0001.0A0B020B.5D504103.0024, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=U6m889ju c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=M51BFTxLslgA:10 a=WtjGUeIEe98SbmMuVg0A:9 a=AmAs7HYEYo2_7xvh:21 a=i6Idrmfwgjngf_50:21 a=CjuIK1q_8ugA:10 a=kyAyQksBrJXqRUp9kFYA:9 a=B2y7HmGcmWMA:10 X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --Apple-Mail=_D6DABFC1-0A66-4D5C-82F0-60D31AF39C10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Observed on macOS as well. Reason: free_cons has the condition if (INT_ADD_WRAPV (consing_until_gc, sizeof *ptr, &consing_until_gc)) which will return true (overflow) if consing_until_gc is negative, which = is kind of defensible since sizeof is unsigned which causes the sum = (consing_until_gc + sizeof *ptr) to be a large unsigned number that = doesn't fit into consing_until_gc. Clang 10 defines __GNUC__ to 4 which causes intprops.h to not use = __builtin_add_overflow despite that being present and working. Casting the sizeof should fix it; patch attached. --Apple-Mail=_D6DABFC1-0A66-4D5C-82F0-60D31AF39C10 Content-Disposition: attachment; filename=0001-Avoid-unsigned-addend-in-overflow-check-bug-37006.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="0001-Avoid-unsigned-addend-in-overflow-check-bug-37006.patch" Content-Transfer-Encoding: quoted-printable =46rom=20f733339714cab022cbbdea06148795d452b183fe=20Mon=20Sep=2017=20= 00:00:00=202001=0AFrom:=20=3D?UTF-8?q?Mattias=3D20Engdeg=3DC3=3DA5rd?=3D=20= =0ADate:=20Sun,=2011=20Aug=202019=2018:11:54=20+0200=0A= Subject:=20[PATCH]=20Avoid=20unsigned=20addend=20in=20overflow=20check=20= (bug#37006)=0A=0A*=20src/alloc.c=20(free_cons):=20Cast=20addend=20to=20= avoid=20spurious=20overflow=20when=0Aconsing_until_gc=20is=20negative.=0A= ---=0A=20src/alloc.c=20|=203=20++-=0A=201=20file=20changed,=202=20= insertions(+),=201=20deletion(-)=0A=0Adiff=20--git=20a/src/alloc.c=20= b/src/alloc.c=0Aindex=205e089311a2..d416d32743=20100644=0A---=20= a/src/alloc.c=0A+++=20b/src/alloc.c=0A@@=20-2542,7=20+2542,8=20@@=20= free_cons=20(struct=20Lisp_Cons=20*ptr)=0A=20=20=20ptr->u.s.u.chain=20=3D=20= cons_free_list;=0A=20=20=20ptr->u.s.car=20=3D=20dead_object=20();=0A=20=20= =20cons_free_list=20=3D=20ptr;=0A-=20=20if=20(INT_ADD_WRAPV=20= (consing_until_gc,=20sizeof=20*ptr,=20&consing_until_gc))=0A+=20=20if=20= (INT_ADD_WRAPV=20(consing_until_gc,=20(object_ct)=20sizeof=20*ptr,=0A+=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= &consing_until_gc))=0A=20=20=20=20=20consing_until_gc=20=3D=20= OBJECT_CT_MAX;=0A=20=20=20gcstat.total_free_conses++;=0A=20}=0A--=20=0A= 2.20.1=20(Apple=20Git-117)=0A=0A= --Apple-Mail=_D6DABFC1-0A66-4D5C-82F0-60D31AF39C10-- From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Aug 2019 17:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: jrm@ftfl.ca, eggert@cs.ucla.edu, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156554325914371 (code B ref 37006); Sun, 11 Aug 2019 17:08:01 +0000 Received: (at 37006) by debbugs.gnu.org; 11 Aug 2019 17:07:39 +0000 Received: from localhost ([127.0.0.1]:45752 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwrJj-0003jj-A0 for submit@debbugs.gnu.org; Sun, 11 Aug 2019 13:07:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45851) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwrJi-0003jV-2Z for 37006@debbugs.gnu.org; Sun, 11 Aug 2019 13:07:38 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hwrJc-0004uM-9C; Sun, 11 Aug 2019 13:07:32 -0400 Received: from [176.228.60.248] (port=2026 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hwrJb-0001Nn-N9; Sun, 11 Aug 2019 13:07:32 -0400 Date: Sun, 11 Aug 2019 20:07:15 +0300 Message-Id: <83ftm7tyv0.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <24BB9DB5-D832-462F-A03C-5595A80B6973@acm.org> (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Sun, 11 Aug 2019 18:23:28 +0200) References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <24BB9DB5-D832-462F-A03C-5595A80B6973@acm.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Mattias Engdegård > Date: Sun, 11 Aug 2019 18:23:28 +0200 > Cc: Eli Zaretskii , Paul Eggert , > 37006@debbugs.gnu.org > > Observed on macOS as well. Reason: free_cons has the condition > > if (INT_ADD_WRAPV (consing_until_gc, sizeof *ptr, &consing_until_gc)) > > which will return true (overflow) if consing_until_gc is negative, which is kind of defensible since sizeof is unsigned which causes the sum (consing_until_gc + sizeof *ptr) to be a large unsigned number that doesn't fit into consing_until_gc. > > Clang 10 defines __GNUC__ to 4 which causes intprops.h to not use __builtin_add_overflow despite that being present and working. > > Casting the sizeof should fix it; patch attached. I believe it should be fixed now. From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Aug 2019 02:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Joseph Mingrone Cc: mattiase@acm.org, eggert@cs.ucla.edu, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.15655771041705 (code B ref 37006); Mon, 12 Aug 2019 02:32:01 +0000 Received: (at 37006) by debbugs.gnu.org; 12 Aug 2019 02:31:44 +0000 Received: from localhost ([127.0.0.1]:46003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hx07b-0000R0-QV for submit@debbugs.gnu.org; Sun, 11 Aug 2019 22:31:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48358) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hx07Z-0000Kq-Lg for 37006@debbugs.gnu.org; Sun, 11 Aug 2019 22:31:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43609) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hx07T-0004R8-HS; Sun, 11 Aug 2019 22:31:35 -0400 Received: from [176.228.60.248] (port=4439 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hx07S-0000TZ-Cq; Sun, 11 Aug 2019 22:31:35 -0400 Date: Mon, 12 Aug 2019 05:31:18 +0300 Message-Id: <83a7cft8qx.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <86pnlbphus.fsf@phe.ftfl.ca> (message from Joseph Mingrone on Sun, 11 Aug 2019 17:28:11 -0300) References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Joseph Mingrone > Cc: Mattias Engdegård , > eggert@cs.ucla.edu > Date: Sun, 11 Aug 2019 17:28:11 -0300 > > > Thanks, I fixed this slightly differently, in a way that makes it more > > explicit why we need a non-trivial code there. Joseph, please see if > > the latest master fixes the problem. > > > (IMNSHO, this issue makes INT_ADD_WRAPV and friends unsafe; at the > > very least this caveat should be prominently documented in Gnulib's > > intprops.h.) > > I have been running 94644d8 for the past hour or so and resident memory for the Emacs process is up over 1300 MB. Also with `garbage-collection-messages' set to t, I do not see any messages about garbage collection. Are you saying that the fix didn't solve the problem for you? I definitely saw a lot of GC messages after the fix where I didn't before. For example, if you visit xdisp.c from the Emacs sources and page through it with C-v, don't you see a lot of GC messages? > I should also add that after my initial report, running 26de2d42, I did eventually start seeing garbage collection messages and the memory usage stopped increasing. Something must have triggered garbage collection to start again. After a lot of consing, the GC would come back for a while, until it would be effectively disabled again by some opportune code path. If you see no GC messages for a long time, attach a debugger and look at the value of consing_until_gc. If its value is huge, around LONG_MAX, the problem is still not completely solved. From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Joseph Mingrone Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Aug 2019 14:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: mattiase@acm.org, eggert@cs.ucla.edu, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.15656204703630 (code B ref 37006); Mon, 12 Aug 2019 14:35:02 +0000 Received: (at 37006) by debbugs.gnu.org; 12 Aug 2019 14:34:30 +0000 Received: from localhost ([127.0.0.1]:47288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxBP3-0000wU-UN for submit@debbugs.gnu.org; Mon, 12 Aug 2019 10:34:30 -0400 Received: from mail-qt1-f169.google.com ([209.85.160.169]:35106) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxBP1-0000wG-AG for 37006@debbugs.gnu.org; Mon, 12 Aug 2019 10:34:27 -0400 Received: by mail-qt1-f169.google.com with SMTP id u34so3688518qte.2 for <37006@debbugs.gnu.org>; Mon, 12 Aug 2019 07:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftfl.ca; s=google; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=Y6r/owwUTf9wjADm6W92GeOotxDw+6CboKF7B1mFarA=; b=NbFGwRzMTvd6V6gysPSt3zLv14dzNKW6QqRR0B5sC1nvFo0vIwDVx3CqqWKRVB3fN4 RLC+N92abDMegyH05QKc9vrIB8g0hnaPzkp/kIFJCbD3Ujf8/6nsZXpqhe8xDTblvZh+ vBryT4NpjMUF0+KfvPEv2l4+cvfzUqzU2QOjM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=Y6r/owwUTf9wjADm6W92GeOotxDw+6CboKF7B1mFarA=; b=ZzWJ36U3JkiDqgYmQyH422R8BPJHlSpHCU13KnSZQmv/Dix6azbkEtqI2YD15h6z9w 9aZlABgsX2FVHq9yJdRCmh6V8w9lrMG7mqGrYbZrOci+HyyXGJOUIv4LTujnYXGSKs5+ D/zgRMPwmAWE2ST7U1E1nZhiEsrWAewvZdfrj2BbYN6yzSj9udGWfV03DeN2spD7F4zv uurHBPygO1BuPR390Fc420XB6rp4AQDUP7hUuuoFhEPBmh+li4LQCM2YXvBYoPoa1IQg az1DpPTx5RMMPy7YduXiwkNg5BvWyGgMmj/mjWRpOsbMxRssS6o/96ErvXSC4Xs/B3RA xbfQ== X-Gm-Message-State: APjAAAU0BX0x21ooJ8B0c437xgC5W96sevTq+sCdmZiqgHeYDEDFulhP dWhjVRx12T4Nr1jKYTbftnjqbOJ4ygU= X-Google-Smtp-Source: APXvYqziAG+2GufOhHlGOY5IeFaEYTWQbCzw1snapU3GpyjDZSh6KWMezU07Kx1FMHM1nTneYxbJHQ== X-Received: by 2002:ac8:67c7:: with SMTP id r7mr6008039qtp.78.1565620461280; Mon, 12 Aug 2019 07:34:21 -0700 (PDT) Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-142-167-140-18.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.167.140.18]) by smtp.gmail.com with ESMTPSA id t76sm48169295qke.79.2019.08.12.07.34.19 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 12 Aug 2019 07:34:19 -0700 (PDT) From: Joseph Mingrone References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> Date: Mon, 12 Aug 2019 11:34:18 -0300 In-Reply-To: <83a7cft8qx.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 12 Aug 2019 05:31:18 +0300") Message-ID: <868srysb9x.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> From: Joseph Mingrone >> Cc: Mattias Engdeg=C3=A5rd , >> eggert@cs.ucla.edu >> Date: Sun, 11 Aug 2019 17:28:11 -0300 >> > Thanks, I fixed this slightly differently, in a way that makes it more >> > explicit why we need a non-trivial code there. Joseph, please see if >> > the latest master fixes the problem. >> > (IMNSHO, this issue makes INT_ADD_WRAPV and friends unsafe; at the >> > very least this caveat should be prominently documented in Gnulib's >> > intprops.h.) >> I have been running 94644d8 for the past hour or so and resident >> memory for the Emacs process is up over 1300 MB. Also with >> `garbage-collection-messages' set to t, I do not see any messages >> about garbage collection. > Are you saying that the fix didn't solve the problem for you? I > definitely saw a lot of GC messages after the fix where I didn't > before. For example, if you visit xdisp.c from the Emacs sources and > page through it with C-v, don't you see a lot of GC messages? >> I should also add that after my initial report, running 26de2d42, I >> did eventually start seeing garbage collection messages and the >> memory usage stopped increasing. Something must have triggered >> garbage collection to start again. > After a lot of consing, the GC would come back for a while, until it > would be effectively disabled again by some opportune code path. > If you see no GC messages for a long time, attach a debugger and look > at the value of consing_until_gc. If its value is huge, around > LONG_MAX, the problem is still not completely solved. The fix did not initially work for me. I tested a bit more. With 1. emacs -Q 2. (setq garbage-collection-messages t) 3. page through xdisp.c I saw lots of garbage collection messages. But, with my init.el there were no such messages. My init.el looked like this. =2D--------------------------------------------------- (setq gc-cons-threshold most-positive-fixnum) ;; contents of init.el here (setq gc-cons-threshold 800000) ;; default value =2D--------------------------------------------------- When I removed the surrounding setqs, garbage collection message were shown again when paging through xdisp.c. I assume that temporarily setting `gc-cons-threshold' to a large number to temporarily prevent garbage collection, then setting it back to a reasonable value should be acceptable. Help for `gc-cons-threshold' says By binding this temporarily to a large number, you can effectively prevent garbage collection during a part of the program. =2D- Joseph --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKgBAEBCgCKFiEEVbCTpybDiFVxIrrVNqQMg7DW754FAl1ReOpfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDU1 QjA5M0E3MjZDMzg4NTU3MTIyQkFENTM2QTQwQzgzQjBENkVGOUUMHGpybUBmdGZs LmNhAAoJEDakDIOw1u+eZIoP/jUm0zVwfFetu294y55U04IEmr/pZlu6+vDmIW75 rK+bm2SCVspM/ioh2VB0pvQK8WY0UKuNMkj2p028Y9RGzUQ82AQxRK7b+UiF5d41 2Zj7fDuIKc+FQeXzgdfUNn11Iy4Y4TlWHbZVn9A9qZuafaZ4SlWmjoZ/Vp/r8n2A Dkqk0jUlZQw414FW/fk1zf7Bu1vz2UL+Un+EaaoLaDPofAGjXdZJKPh+Des5452M blLBufoAX2+upg0T89RjTPhcms2st4Lf30QVuOsW+bvB5/3+8vRN5fH1l4usYSgL 1UQaqrp1H8LBMhpqI12abIs4tSBfuk4fj7YBsvogM0X6hhOfwGFKFNYCTBaZorUy mCkvaYdI+xAMS2AYnHUrKEzeCSchuUS5yxp4BpQZn4+q/G6OXHyBtL52e9GDI4Vk zPzw9JzRYPFG3R6k6QVG1JVExRzw9fOKr4N+GHPA5bTpA1/wFtbiAOfIe9E1XH+v nH9TUXr0AtCgR1NyZan45Cn6o0vIrriHVGSBgcvItGayDM6NXSZNji0Rf0aaEwDA zFoBjr6PBoaZec0bO8q1Q4q0pPxPqEegARROesjRM3MjxvmzTmHlCNE12lW3BrHo FkCLh5U3RVAX+2QXB+rqJcZDkkieziwJqfg/AhgQ9jCew30qCym7E9jWqpIkbSZC LUL4 =xDb9 -----END PGP SIGNATURE----- --=-=-=-- From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Aug 2019 16:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Joseph Mingrone , Paul Eggert Cc: mattiase@acm.org, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156562860816311 (code B ref 37006); Mon, 12 Aug 2019 16:51:02 +0000 Received: (at 37006) by debbugs.gnu.org; 12 Aug 2019 16:50:08 +0000 Received: from localhost ([127.0.0.1]:47347 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxDWK-0004F1-Cr for submit@debbugs.gnu.org; Mon, 12 Aug 2019 12:50:08 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44493) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxDWF-0004EO-M4 for 37006@debbugs.gnu.org; Mon, 12 Aug 2019 12:50:06 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53015) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hxDW9-0003FP-KN; Mon, 12 Aug 2019 12:49:57 -0400 Received: from [176.228.60.248] (port=1033 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hxDW9-0003I2-1J; Mon, 12 Aug 2019 12:49:57 -0400 Date: Mon, 12 Aug 2019 19:49:43 +0300 Message-Id: <83wofis508.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <868srysb9x.fsf@phe.ftfl.ca> (message from Joseph Mingrone on Mon, 12 Aug 2019 11:34:18 -0300) References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Joseph Mingrone > Cc: mattiase@acm.org, eggert@cs.ucla.edu, 37006@debbugs.gnu.org > Date: Mon, 12 Aug 2019 11:34:18 -0300 > > The fix did not initially work for me. I tested a bit more. With > > 1. emacs -Q > 2. (setq garbage-collection-messages t) > 3. page through xdisp.c > > I saw lots of garbage collection messages. But, with my init.el there > were no such messages. My init.el looked like this. > > ---------------------------------------------------- > (setq gc-cons-threshold most-positive-fixnum) > > ;; contents of init.el here > > (setq gc-cons-threshold 800000) ;; default value > ---------------------------------------------------- > > When I removed the surrounding setqs, garbage collection message were > shown again when paging through xdisp.c. > > I assume that temporarily setting `gc-cons-threshold' to a large number > to temporarily prevent garbage collection, then setting it back to a > reasonable value should be acceptable. Yes, of course. There's a separate bug in the recent GC-related changes. Thanks for pointing this out. Paul, the current method of updating consing_until_gc only in garbage_collect_1 isn't workable, because it doesn't support the (very popular nowadays) paradigm of temporarily setting gc-cons-threshold very high: doing so avoids calling garbage_collect_1, and thus the change of the threshold back to a lower value is never seen. We must have something in maybe_gc to notice the change and recompute the threshold. We must also notice the memory-full condition there. We need to fix this ASAP, please. I also don't think I understand the details of the threshold calculations: if (!NILP (Vmemory_full)) consing_until_gc = memory_full_cons_threshold; else { intptr_t threshold = min (max (GC_DEFAULT_THRESHOLD, gc_cons_threshold >> 3), OBJECT_CT_MAX); if (FLOATP (Vgc_cons_percentage)) { double tot = (XFLOAT_DATA (Vgc_cons_percentage) * total_bytes_of_live_objects ()); if (threshold < tot) { if (tot < OBJECT_CT_MAX) threshold = tot; else threshold = OBJECT_CT_MAX; } } consing_until_gc = threshold; } First, gc_cons_threshold is an EMACS_INT, so putting its value into intptr_t is wrong in 32-bit builds --with-wide-int, right? For the same reason, using intptr_t for OBJECT_CT_MAX is wrong in such a build. And second, why does the code divide gc_cons_threshold by 8? If the value of gc_cons_threshold is most-positive-fixnum, that is wrong, I think. Did you mean to divide GC_DEFAULT_THRESHOLD instead? From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Aug 2019 17:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: Joseph Mingrone , Paul Eggert , 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156562926117390 (code B ref 37006); Mon, 12 Aug 2019 17:01:01 +0000 Received: (at 37006) by debbugs.gnu.org; 12 Aug 2019 17:01:01 +0000 Received: from localhost ([127.0.0.1]:47351 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxDgq-0004WP-KB for submit@debbugs.gnu.org; Mon, 12 Aug 2019 13:01:00 -0400 Received: from mail1430c50.megamailservers.eu ([91.136.14.30]:52804 helo=mail118c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxDgn-0004WA-3h for 37006@debbugs.gnu.org; Mon, 12 Aug 2019 13:00:58 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1565629241; bh=RmmUz9/rkFpHWAxAqJoDF0cKLygOB8LY2cy5UzEPbbk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=n5zb17kSghIDfV1WqHGl/96hqpBsAkp3kxnfUG6q8Gq7UgdEvgPmRzifF1LP6kamt 0u4BbXj+IoKHlPuJVcf/jFJDmD3jykQbYimTYNGx/QpCIQJ1BQOXFo42S7DWBps+yi dbR1q+lK2xWXcqlpVDbnwi6+pu/2fh+K8gM485eo= Feedback-ID: mattiase@acm.or Received: from [192.168.0.4] ([188.150.171.71]) (authenticated bits=0) by mail118c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id x7CH0b1l019414; Mon, 12 Aug 2019 17:00:39 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= In-Reply-To: <83wofis508.fsf@gnu.org> Date: Mon, 12 Aug 2019 19:00:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> <83wofis508.fsf@gnu.org> X-Mailer: Apple Mail (2.3445.104.11) X-CTCH-RefID: str=0001.0A0B0205.5D519B39.000C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=Mqx8FVSe c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=mDV3o1hIAAAA:8 a=MnNeRBu_eXT3IsHPgBoA:9 a=CjuIK1q_8ugA:10 a=_FVE-zBwftR9WsbkzFJk:22 X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 12 aug. 2019 kl. 18.49 skrev Eli Zaretskii : > [...] We must > have something in maybe_gc to notice the change and recompute the > threshold. We must also notice the memory-full condition there. What about biasing consing_until_gc by gc_cons_threshold, and change the = condition in maybe_gc to (the moral equivalent of) if (consing_until_gc < gc_cons_threshold) ? It is practically as cheap as the current test against 0. From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Aug 2019 15:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: jrm@ftfl.ca, eggert@cs.ucla.edu, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.1565710683684 (code B ref 37006); Tue, 13 Aug 2019 15:39:02 +0000 Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 15:38:03 +0000 Received: from localhost ([127.0.0.1]:48568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxYs7-0000Ay-3W for submit@debbugs.gnu.org; Tue, 13 Aug 2019 11:38:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38579) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxYs5-0000AI-DL for 37006@debbugs.gnu.org; Tue, 13 Aug 2019 11:38:01 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40273) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hxYrz-0003sj-J5; Tue, 13 Aug 2019 11:37:55 -0400 Received: from [176.228.60.248] (port=1323 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hxYry-0007pt-Vf; Tue, 13 Aug 2019 11:37:55 -0400 Date: Tue, 13 Aug 2019 18:37:42 +0300 Message-Id: <83h86lrs8p.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Mon, 12 Aug 2019 19:00:37 +0200) References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> <83wofis508.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Mattias Engdegård > Date: Mon, 12 Aug 2019 19:00:37 +0200 > Cc: Joseph Mingrone , Paul Eggert , > 37006@debbugs.gnu.org > > What about biasing consing_until_gc by gc_cons_threshold, and change the condition in maybe_gc to (the moral equivalent of) > > if (consing_until_gc < gc_cons_threshold) > > ? It is practically as cheap as the current test against 0. Yes, but the full calculation of the threshold is more complicated than that. For starters, how do you handle gc_cons_threshold values that are smaller than GC_DEFAULT_THRESHOLD / 10 under your proposal? There are use cases where the value was below that before and is above now, or the other way around, or was below and stays below. And that's even before we consider other complications: when memory-full is non-nil, we should use a different threshold; and what about user changes to gc-cons-percentage? From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Aug 2019 16:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: jrm@ftfl.ca, eggert@cs.ucla.edu, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.15657149057239 (code B ref 37006); Tue, 13 Aug 2019 16:49:02 +0000 Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 16:48:25 +0000 Received: from localhost ([127.0.0.1]:48600 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxZyD-0001sh-2O for submit@debbugs.gnu.org; Tue, 13 Aug 2019 12:48:25 -0400 Received: from mail154c50.megamailservers.eu ([91.136.10.164]:55714 helo=mail50c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxZy9-0001sV-LH for 37006@debbugs.gnu.org; Tue, 13 Aug 2019 12:48:23 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1565714889; bh=pA9IrvZt+YxsYFEkJaBHP92ILrbaH2X9isYjgHDxpz8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ONp6h4DByyXVDY5K1zqluKb2s+I+EoCdiiAdCJCON9pyXaiNuyHz88xxUy7CSddjU rn+051DVDzALK0kSlCqRDT7o0gk8tjrPB2CL0x5amAgFx3W+hO4cv1rIxXC1BICNpq XzvUlv7hhUqf22V2sNOCecLKvdUjrZCyNchcvu+w= Feedback-ID: mattiase@acm.or Received: from [192.168.0.4] ([188.150.171.71]) (authenticated bits=0) by mail50c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id x7DGm6wv022361; Tue, 13 Aug 2019 16:48:07 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= In-Reply-To: <83h86lrs8p.fsf@gnu.org> Date: Tue, 13 Aug 2019 18:48:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3E8F9821-8C8B-48AD-BC88-7191450C4D7E@acm.org> References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> <83wofis508.fsf@gnu.org> <83h86lrs8p.fsf@gnu.org> X-Mailer: Apple Mail (2.3445.104.11) X-CTCH-RefID: str=0001.0A0B020D.5D52E9C9.000E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=CNcEoyjD c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=mDV3o1hIAAAA:8 a=MSCd30SWwwHpbCGJnNgA:9 a=CjuIK1q_8ugA:10 a=_FVE-zBwftR9WsbkzFJk:22 X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 13 aug. 2019 kl. 17.37 skrev Eli Zaretskii : >=20 > Yes, but the full calculation of the threshold is more complicated > than that. For starters, how do you handle gc_cons_threshold values > that are smaller than GC_DEFAULT_THRESHOLD / 10 under your proposal? > There are use cases where the value was below that before and is above > now, or the other way around, or was below and stays below. If a change to gc_cons_threshold has us end up in garbage_collect too = soon, we can just adjust the bias and consing_until_gc and continue; the = cost for doing so is small and amortised. Conversely, if the user raises = gc_cons_threshold beyond the limit (OBJECT_CT_MAX), the intention is = clearly to inhibit GC anyway. > And that's even before we consider other complications: when > memory-full is non-nil, we should use a different threshold; and what > about user changes to gc-cons-percentage? The check for memory-full was already eliminated from maybe_gc by = changing consing_until_gc when that condition occurs, which seems = reasonable enough. Regarding changes gc-cons-percentage, the effect will = just be delayed to next GC --- is this really harmful? I could be wrong about all this; I'm a bit confused by the threshold = computation, too. However, Paul's consolidation of conditions in the hot = and inlined maybe_gc makes eminently sense to me. From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Aug 2019 17:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: jrm@ftfl.ca, eggert@cs.ucla.edu, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.15657158748798 (code B ref 37006); Tue, 13 Aug 2019 17:05:01 +0000 Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 17:04:34 +0000 Received: from localhost ([127.0.0.1]:48604 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxaDp-0002Hp-If for submit@debbugs.gnu.org; Tue, 13 Aug 2019 13:04:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49759) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxaDn-0002HP-T4 for 37006@debbugs.gnu.org; Tue, 13 Aug 2019 13:04:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41900) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hxaDi-0002mt-7s; Tue, 13 Aug 2019 13:04:26 -0400 Received: from [176.228.60.248] (port=2871 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hxaDh-0007Yl-L0; Tue, 13 Aug 2019 13:04:26 -0400 Date: Tue, 13 Aug 2019 20:04:13 +0300 Message-Id: <83ftm5ro8i.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <3E8F9821-8C8B-48AD-BC88-7191450C4D7E@acm.org> (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Tue, 13 Aug 2019 18:48:05 +0200) References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> <83wofis508.fsf@gnu.org> <83h86lrs8p.fsf@gnu.org> <3E8F9821-8C8B-48AD-BC88-7191450C4D7E@acm.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Mattias Engdegård > Date: Tue, 13 Aug 2019 18:48:05 +0200 > Cc: jrm@ftfl.ca, eggert@cs.ucla.edu, 37006@debbugs.gnu.org > > > Yes, but the full calculation of the threshold is more complicated > > than that. For starters, how do you handle gc_cons_threshold values > > that are smaller than GC_DEFAULT_THRESHOLD / 10 under your proposal? > > There are use cases where the value was below that before and is above > > now, or the other way around, or was below and stays below. > > If a change to gc_cons_threshold has us end up in garbage_collect too soon, we can just adjust the bias and consing_until_gc and continue; the cost for doing so is small and amortised. Conversely, if the user raises gc_cons_threshold beyond the limit (OBJECT_CT_MAX), the intention is clearly to inhibit GC anyway. > > > And that's even before we consider other complications: when > > memory-full is non-nil, we should use a different threshold; and what > > about user changes to gc-cons-percentage? > > The check for memory-full was already eliminated from maybe_gc by changing consing_until_gc when that condition occurs, which seems reasonable enough. Regarding changes gc-cons-percentage, the effect will just be delayed to next GC --- is this really harmful? IOW, you think that whatever this changes in user-facing behavior is unimportant, and we shouldn't be bothered about it. I happen to disagree. > I could be wrong about all this; I'm a bit confused by the threshold computation, too. However, Paul's consolidation of conditions in the hot and inlined maybe_gc makes eminently sense to me. I cannot say the same thing myself, sorry. Making a frequent operation faster definitely makes sense, even if the speedup is minor. But doing that and as result breaking use cases that worked for years, or even just changing their effects in a tangible manner? what's our excuse for that? From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Aug 2019 17:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii , Joseph Mingrone Cc: mattiase@acm.org, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156571692110756 (code B ref 37006); Tue, 13 Aug 2019 17:22:02 +0000 Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 17:22:01 +0000 Received: from localhost ([127.0.0.1]:48609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxaUj-0002nN-6W for submit@debbugs.gnu.org; Tue, 13 Aug 2019 13:22:01 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxaUg-0002n6-IN for 37006@debbugs.gnu.org; Tue, 13 Aug 2019 13:21:59 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C5CD1162729; Tue, 13 Aug 2019 10:21:52 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id tEzleCR-qOCF; Tue, 13 Aug 2019 10:21:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DF3E116272B; Tue, 13 Aug 2019 10:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mDfK3R24W3tt; Tue, 13 Aug 2019 10:21:51 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 8D7FF162729; Tue, 13 Aug 2019 10:21:51 -0700 (PDT) References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> <83wofis508.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> Date: Tue, 13 Aug 2019 10:21:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <83wofis508.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------3A5BBA64323C417A2FD237A2" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------3A5BBA64323C417A2FD237A2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Eli Zaretskii wrote: > We must > have something in maybe_gc to notice the change and recompute the > threshold. I don't see why the threshold needs to be recomputed on each maybe_gc call. I suppose we could add a new builtin variable type, so that the threshold could be recomputed whenever GC-related builtin variables are changed; that should do the trick without slowing down maybe_gc. But is it that important to recalculate the GC threshold immediately? Variables like gc-cons-threshold aren't intended for fine-grained control over exactly when the GC is called; they're merely advice. > We must also notice the memory-full condition there. memory_full already does that, no? It sets consing_until_gc. Or are you thinking of some other memory-full condition? > if (!NILP (Vmemory_full)) > consing_until_gc = memory_full_cons_threshold; > else > { > intptr_t threshold = min (max (GC_DEFAULT_THRESHOLD, > gc_cons_threshold >> 3), > OBJECT_CT_MAX); > if (FLOATP (Vgc_cons_percentage)) > { > double tot = (XFLOAT_DATA (Vgc_cons_percentage) > * total_bytes_of_live_objects ()); > if (threshold < tot) > { > if (tot < OBJECT_CT_MAX) > threshold = tot; > else > threshold = OBJECT_CT_MAX; > } > } > consing_until_gc = threshold; > } > > First, gc_cons_threshold is an EMACS_INT, so putting its value into > intptr_t is wrong in 32-bit builds --with-wide-int, right? That's not a problem, since the above code does min (..., OBJECT_CT_MAX) on the result before storing it into intptr_t. > using intptr_t for OBJECT_CT_MAX is wrong in such a build. I don't see why it's wrong. The idea is to count the total number of object bytes in use. This cannot exceed the number of bytes addressable by pointers regardless of the width of EMACS_INT, so intptr_t is appropriate for such counts. > And second, why does the code divide gc_cons_threshold by 8? If the > value of gc_cons_threshold is most-positive-fixnum, that is wrong, I > think. Did you mean to divide GC_DEFAULT_THRESHOLD instead? Right you are; that's a typo. Thanks. I fixed that in master in the attached patch. --------------3A5BBA64323C417A2FD237A2 Content-Type: text/x-patch; name="0001-Fix-GC-threshold-typo.patch" Content-Disposition: attachment; filename="0001-Fix-GC-threshold-typo.patch" Content-Transfer-Encoding: quoted-printable >From 1e5bda273a67f960fb834007f4653a630cd67ce9 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 13 Aug 2019 10:03:41 -0700 Subject: [PATCH] Fix GC threshold typo MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit Problem reported by Eli Zaretskii (Bug#37006#25). * src/alloc.c (garbage_collect_1): Fix typo in threshold calc. Go back to dividing by 10 since the numerator=E2=80=99s a constant now. Problem introduced in 2019-07-21T02:40:03Z!eggert@cs.ucla.edu. --- src/alloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/alloc.c b/src/alloc.c index 39833f8dec..c7419e2fa5 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -5932,8 +5932,8 @@ garbage_collect_1 (struct gcstat *gcst) consing_until_gc =3D memory_full_cons_threshold; else { - intptr_t threshold =3D min (max (GC_DEFAULT_THRESHOLD, - gc_cons_threshold >> 3), + intptr_t threshold =3D min (max (GC_DEFAULT_THRESHOLD / 10, + gc_cons_threshold), OBJECT_CT_MAX); if (FLOATP (Vgc_cons_percentage)) { --=20 2.17.1 --------------3A5BBA64323C417A2FD237A2-- From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Aug 2019 17:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: jrm@ftfl.ca, eggert@cs.ucla.edu, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156571737211503 (code B ref 37006); Tue, 13 Aug 2019 17:30:02 +0000 Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 17:29:32 +0000 Received: from localhost ([127.0.0.1]:48613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxaby-0002zR-6i for submit@debbugs.gnu.org; Tue, 13 Aug 2019 13:29:32 -0400 Received: from mail212c50.megamailservers.eu ([91.136.10.222]:43224 helo=mail194c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxabu-0002z6-Ts for 37006@debbugs.gnu.org; Tue, 13 Aug 2019 13:29:28 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1565717350; bh=wDnuqTx2/XYcAgR/LZkhOCTJ9q/Yjp+Us3Vb9uIwkr8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=r/LuLFODAEE5XlGi3Vpg4aV8eSFnULfYxMb/MAdYdkEoG0ub4q/14aWxrz/00O1Oh jLykGHygpVslFj4lneirhxouSHJ2L4MwRr8HEOwWyZWscksXzZ+lDJqPW6cvKny1SQ HS283AVR90z5iYWA0sxAK/Ku6amVGo6XPPKpeYMc= Feedback-ID: mattiase@acm.or Received: from [192.168.0.4] ([188.150.171.71]) (authenticated bits=0) by mail194c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id x7DHT8ia017804; Tue, 13 Aug 2019 17:29:09 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= In-Reply-To: <83ftm5ro8i.fsf@gnu.org> Date: Tue, 13 Aug 2019 19:29:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <468CCECA-FC1D-47DD-A690-A3CA96CBF866@acm.org> References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> <83wofis508.fsf@gnu.org> <83h86lrs8p.fsf@gnu.org> <3E8F9821-8C8B-48AD-BC88-7191450C4D7E@acm.org> <83ftm5ro8i.fsf@gnu.org> X-Mailer: Apple Mail (2.3445.104.11) X-CTCH-RefID: str=0001.0A0B0210.5D52F366.0041, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=Df05VMlW c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=mDV3o1hIAAAA:8 a=px8s3ZbfGHmYftafZr4A:9 a=CjuIK1q_8ugA:10 a=_FVE-zBwftR9WsbkzFJk:22 X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 13 aug. 2019 kl. 19.04 skrev Eli Zaretskii : >=20 >> Regarding changes gc-cons-percentage, the effect will just be delayed = to next GC --- is this really harmful? >=20 > IOW, you think that whatever this changes in user-facing behavior is > unimportant, and we shouldn't be bothered about it. I happen to > disagree. In contrast to gc-cons-threshold, we never really promised the effect of = gc-cons-percentage to be immediate, and it seems unlikely that anyone = would use the latter variable in such a way. From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Aug 2019 17:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Paul Eggert Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156571884313811 (code B ref 37006); Tue, 13 Aug 2019 17:55:01 +0000 Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 17:54:03 +0000 Received: from localhost ([127.0.0.1]:48618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxazi-0003ah-Td for submit@debbugs.gnu.org; Tue, 13 Aug 2019 13:54:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55299) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxazg-0003a3-Lv for 37006@debbugs.gnu.org; Tue, 13 Aug 2019 13:54:01 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hxaza-000453-Ou; Tue, 13 Aug 2019 13:53:54 -0400 Received: from [176.228.60.248] (port=1909 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hxazZ-00027B-Q7; Tue, 13 Aug 2019 13:53:54 -0400 Date: Tue, 13 Aug 2019 20:53:38 +0300 Message-Id: <83ef1prly5.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> (message from Paul Eggert on Tue, 13 Aug 2019 10:21:51 -0700) References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> <83wofis508.fsf@gnu.org> <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: mattiase@acm.org, 37006@debbugs.gnu.org > From: Paul Eggert > Date: Tue, 13 Aug 2019 10:21:51 -0700 > > > We must > > have something in maybe_gc to notice the change and recompute the > > threshold. > > I don't see why the threshold needs to be recomputed on each maybe_gc call. I > suppose we could add a new builtin variable type, so that the threshold could be > recomputed whenever GC-related builtin variables are changed; that should do the > trick without slowing down maybe_gc. I don't think I understand what this proposal means in practice. Can you elaborate, or show an example? > But is it that important to recalculate the GC threshold > immediately? How else would you succeed in reacting to the change "soon enough"? In the use case which triggered this bug report, setting gc-cons-threshold to a very large number disables GC for an extremely long time, and all that time the gc-cons-threshold changes made by the user are not acted upon. IOW, we could perhaps explain away a delay of seconds in acting upon the change, but we surely cannot explain away a delay of hours, let alone days. > Variables like gc-cons-threshold aren't intended for fine-grained > control over exactly when the GC is called; they're merely advice. Yes, but abrupt changes, like to most-positive-fixnum and then back to much smaller values, should produce at least approximately the expected behavior. In particular, changing from most-positive-fixnum to a value like 800000 should cause a GC "soon enough". If we don't test the value inside maybe_gc, what alternative mechanisms would you suggest to produce such an effect? > > We must also notice the memory-full condition there. > > memory_full already does that, no? It sets consing_until_gc. It sets it to a positive value, so no immediate GC will follow. The original code was setting the threshold to a very small value, so GC would happen immediately. I think the code in memory_full which sets consing_until_gc should be amended to (a) not raise consing_until_gc if the current value is already below memory_full_cons_threshold, and (b) probably even set it to the negative of sizeof (struct cons_block) so as to cause an immediate GC. > > First, gc_cons_threshold is an EMACS_INT, so putting its value into > > intptr_t is wrong in 32-bit builds --with-wide-int, right? > > That's not a problem, since the above code does min (..., OBJECT_CT_MAX) on the > result before storing it into intptr_t. ??? But that effectively disallows/ignores values of gc-cons-threshold above LONG_MAX. Why would we make such a backward-incompatible change? When the user sets the value of that variable, the variable should keep its value, and we should be able to compare the threshold with the value of the user variable. If nothing else, arbitrarily throwing away high-order bits of the value is a sure path towards bugs due to confusion between these two value ranges. > > using intptr_t for OBJECT_CT_MAX is wrong in such a build. > > I don't see why it's wrong. Because OBJECT_CT_MAX should have the value EMACS_INT_MAX. From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Aug 2019 19:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156572475524309 (code B ref 37006); Tue, 13 Aug 2019 19:33:02 +0000 Received: (at 37006) by debbugs.gnu.org; 13 Aug 2019 19:32:35 +0000 Received: from localhost ([127.0.0.1]:48658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxcX5-0006K1-0L for submit@debbugs.gnu.org; Tue, 13 Aug 2019 15:32:35 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58548) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxcX2-0006Jn-Cf for 37006@debbugs.gnu.org; Tue, 13 Aug 2019 15:32:33 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9DF72162732; Tue, 13 Aug 2019 12:32:26 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id UVck_yB_e_Yq; Tue, 13 Aug 2019 12:32:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 38800162733; Tue, 13 Aug 2019 12:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JvsQf8kSbgcL; Tue, 13 Aug 2019 12:32:25 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id ED71D162732; Tue, 13 Aug 2019 12:32:24 -0700 (PDT) References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> <83wofis508.fsf@gnu.org> <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> <83ef1prly5.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@cs.ucla.edu> Date: Tue, 13 Aug 2019 12:32:24 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <83ef1prly5.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------4523E105E1821A76D13A372E" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------4523E105E1821A76D13A372E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Eli Zaretskii wrote: > OBJECT_CT_MAX should have the value EMACS_INT_MAX. Not if EMACS_INT_MAX < INTPTR_MAX, since object counts might overflow in that case. However, I take your point that consing_until_gc can easily be made to hold any fixnum value, so I installed the first attached patch. This is to some extent overkill, since these variables should not be assumed to have this sort of fine-grained control, but the change is tiny so should be fine. Come to think of it, the limit should be INTMAX_MAX not EMACS_INT_MAX since gc-cons-threshold could exceed EMACS_INT_MAX. So I installed the second attached patch to do that. >> I don't see why the threshold needs to be recomputed on each maybe_gc call. I >> suppose we could add a new builtin variable type, so that the threshold could be >> recomputed whenever GC-related builtin variables are changed; that should do the >> trick without slowing down maybe_gc. > > I don't think I understand what this proposal means in practice. Can > you elaborate, or show an example? The idea would be to have a type that is like struct Lisp_Objfwd but with an extra member, a function to be called whenever the variable is accessed. (Or perhaps two extra members, a getter and a setter.) This could be useful for other builtin vars, I suspect. > How else would you succeed in reacting to the change "soon enough"? There are other possibilities. We could have a timer, for example. >>> We must also notice the memory-full condition there. >> >> memory_full already does that, no? It sets consing_until_gc. > > It sets it to a positive value, so no immediate GC will follow. The > original code was setting the threshold to a very small value, so GC > would happen immediately. Are you talking about the change in commit 2019-07-20T02:40:03Z!eggert@cs.ucla.edu (26de2d42d0460c5b193456950a568cb04a29dc00)? If so, I'm not quite following, as the old code did not GC until consing_since_gc > memory_full_cons_threshold. I expect that the idea was to not thrash doing GCs when memory is full. I think the code in memory_full which sets > consing_until_gc should be amended to (a) not raise consing_until_gc > if the current value is already below memory_full_cons_threshold, and > (b) probably even set it to the negative of sizeof (struct cons_block) > so as to cause an immediate GC. Immediate-GC might cause GC thrashing, no? But (a) makes sense so I installed the third attached patch. --------------4523E105E1821A76D13A372E Content-Type: text/x-patch; name="0001-Let-consing_until_gc-exceed-INTPTR_MAX.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Let-consing_until_gc-exceed-INTPTR_MAX.patch" >From a354736e1dfe5a7e4ddbb1ee7f1373be2b5bbe09 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 13 Aug 2019 12:11:35 -0700 Subject: [PATCH 1/3] Let consing_until_gc exceed INTPTR_MAX Suggested by Eli Zaretskii (Bug#37006#46). * src/alloc.c (consing_until_gc): Now of type consing_ct. All uses changed, so gc-cons-threshold no longer saturates against OBJECT_CT_MAX. (object_ct): Move typedef here from lisp.h. * src/lisp.h (consing_ct, CONSING_CT_MAX): New type and macro. (OBJECT_CT_MAX): Remove. Replace all uses with CONSING_CT_MAX. --- src/alloc.c | 21 ++++++++++----------- src/lisp.h | 10 +++++++--- 2 files changed, 17 insertions(+), 14 deletions(-) diff --git a/src/alloc.c b/src/alloc.c index c7419e2fa5..7bed3f4488 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -224,7 +224,7 @@ struct emacs_globals globals; /* maybe_gc collects garbage if this goes negative. */ -object_ct consing_until_gc; +consing_ct consing_until_gc; #ifdef HAVE_PDUMPER /* Number of finalizers run: used to loop over GC until we stop @@ -236,9 +236,10 @@ int number_finalizers_run; bool gc_in_progress; -/* System byte counts reported by GC. */ +/* System byte and object counts reported by GC. */ typedef uintptr_t byte_ct; +typedef intptr_t object_ct; /* Number of live and free conses etc. */ @@ -2546,7 +2547,7 @@ free_cons (struct Lisp_Cons *ptr) might incorrectly return non-zero. */ int incr = sizeof *ptr; if (INT_ADD_WRAPV (consing_until_gc, incr, &consing_until_gc)) - consing_until_gc = OBJECT_CT_MAX; + consing_until_gc = CONSING_CT_MAX; gcstat.total_free_conses++; } @@ -5501,7 +5502,7 @@ staticpro (Lisp_Object const *varaddress) static void allow_garbage_collection (intmax_t consing) { - consing_until_gc = consing - (OBJECT_CT_MAX - consing_until_gc); + consing_until_gc = consing - (CONSING_CT_MAX - consing_until_gc); garbage_collection_inhibited--; } @@ -5511,7 +5512,7 @@ inhibit_garbage_collection (void) ptrdiff_t count = SPECPDL_INDEX (); record_unwind_protect_intmax (allow_garbage_collection, consing_until_gc); garbage_collection_inhibited++; - consing_until_gc = OBJECT_CT_MAX; + consing_until_gc = CONSING_CT_MAX; return count; } @@ -5817,7 +5818,7 @@ garbage_collect_1 (struct gcstat *gcst) /* In case user calls debug_print during GC, don't let that cause a recursive GC. */ - consing_until_gc = OBJECT_CT_MAX; + consing_until_gc = CONSING_CT_MAX; /* Save what's currently displayed in the echo area. Don't do that if we are GC'ing because we've run out of memory, since @@ -5932,19 +5933,17 @@ garbage_collect_1 (struct gcstat *gcst) consing_until_gc = memory_full_cons_threshold; else { - intptr_t threshold = min (max (GC_DEFAULT_THRESHOLD / 10, - gc_cons_threshold), - OBJECT_CT_MAX); + consing_ct threshold = max (gc_cons_threshold, GC_DEFAULT_THRESHOLD / 10); if (FLOATP (Vgc_cons_percentage)) { double tot = (XFLOAT_DATA (Vgc_cons_percentage) * total_bytes_of_live_objects ()); if (threshold < tot) { - if (tot < OBJECT_CT_MAX) + if (tot < CONSING_CT_MAX) threshold = tot; else - threshold = OBJECT_CT_MAX; + threshold = CONSING_CT_MAX; } } consing_until_gc = threshold; diff --git a/src/lisp.h b/src/lisp.h index 63baab5d63..043f2f738e 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -3793,9 +3793,13 @@ extern void flush_stack_call_func (void (*func) (void *arg), void *arg); extern void garbage_collect (void); extern const char *pending_malloc_warning; extern Lisp_Object zero_vector; -typedef intptr_t object_ct; /* Signed type of object counts reported by GC. */ -#define OBJECT_CT_MAX INTPTR_MAX -extern object_ct consing_until_gc; +#define CONSING_CT_MAX max (INTPTR_MAX, EMACS_INT_MAX) +#if CONSING_CT_MAX == INTPTR_MAX +typedef intptr_t consing_ct; +#else +typedef EMACS_INT consing_ct; +#endif +extern consing_ct consing_until_gc; #ifdef HAVE_PDUMPER extern int number_finalizers_run; #endif -- 2.17.1 --------------4523E105E1821A76D13A372E Content-Type: text/x-patch; name="0002-Let-consing_until_gc-exceed-EMACS_INT_MAX.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0002-Let-consing_until_gc-exceed-EMACS_INT_MAX.patch" >From b80559be212292d44ce14ca5e94505cab4d9a868 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 13 Aug 2019 12:20:40 -0700 Subject: [PATCH 2/3] Let consing_until_gc exceed EMACS_INT_MAX This builds on the previous patch. * src/alloc.c (consing_until_gc): Now of type intmax_t, since gc-cons-threshold can be up to INTMAX_MAX. All uses changed. * src/lisp.h (CONSING_CT_MAX, consing_ct): Remove. --- src/alloc.c | 16 ++++++++-------- src/lisp.h | 8 +------- 2 files changed, 9 insertions(+), 15 deletions(-) diff --git a/src/alloc.c b/src/alloc.c index 7bed3f4488..14b0a7b838 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -224,7 +224,7 @@ struct emacs_globals globals; /* maybe_gc collects garbage if this goes negative. */ -consing_ct consing_until_gc; +intmax_t consing_until_gc; #ifdef HAVE_PDUMPER /* Number of finalizers run: used to loop over GC until we stop @@ -2547,7 +2547,7 @@ free_cons (struct Lisp_Cons *ptr) might incorrectly return non-zero. */ int incr = sizeof *ptr; if (INT_ADD_WRAPV (consing_until_gc, incr, &consing_until_gc)) - consing_until_gc = CONSING_CT_MAX; + consing_until_gc = INTMAX_MAX; gcstat.total_free_conses++; } @@ -5502,7 +5502,7 @@ staticpro (Lisp_Object const *varaddress) static void allow_garbage_collection (intmax_t consing) { - consing_until_gc = consing - (CONSING_CT_MAX - consing_until_gc); + consing_until_gc = consing - (INTMAX_MAX - consing_until_gc); garbage_collection_inhibited--; } @@ -5512,7 +5512,7 @@ inhibit_garbage_collection (void) ptrdiff_t count = SPECPDL_INDEX (); record_unwind_protect_intmax (allow_garbage_collection, consing_until_gc); garbage_collection_inhibited++; - consing_until_gc = CONSING_CT_MAX; + consing_until_gc = INTMAX_MAX; return count; } @@ -5818,7 +5818,7 @@ garbage_collect_1 (struct gcstat *gcst) /* In case user calls debug_print during GC, don't let that cause a recursive GC. */ - consing_until_gc = CONSING_CT_MAX; + consing_until_gc = INTMAX_MAX; /* Save what's currently displayed in the echo area. Don't do that if we are GC'ing because we've run out of memory, since @@ -5933,17 +5933,17 @@ garbage_collect_1 (struct gcstat *gcst) consing_until_gc = memory_full_cons_threshold; else { - consing_ct threshold = max (gc_cons_threshold, GC_DEFAULT_THRESHOLD / 10); + intmax_t threshold = max (gc_cons_threshold, GC_DEFAULT_THRESHOLD / 10); if (FLOATP (Vgc_cons_percentage)) { double tot = (XFLOAT_DATA (Vgc_cons_percentage) * total_bytes_of_live_objects ()); if (threshold < tot) { - if (tot < CONSING_CT_MAX) + if (tot < INTMAX_MAX) threshold = tot; else - threshold = CONSING_CT_MAX; + threshold = INTMAX_MAX; } } consing_until_gc = threshold; diff --git a/src/lisp.h b/src/lisp.h index 043f2f738e..0370c52fad 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -3793,13 +3793,7 @@ extern void flush_stack_call_func (void (*func) (void *arg), void *arg); extern void garbage_collect (void); extern const char *pending_malloc_warning; extern Lisp_Object zero_vector; -#define CONSING_CT_MAX max (INTPTR_MAX, EMACS_INT_MAX) -#if CONSING_CT_MAX == INTPTR_MAX -typedef intptr_t consing_ct; -#else -typedef EMACS_INT consing_ct; -#endif -extern consing_ct consing_until_gc; +extern intmax_t consing_until_gc; #ifdef HAVE_PDUMPER extern int number_finalizers_run; #endif -- 2.17.1 --------------4523E105E1821A76D13A372E Content-Type: text/x-patch; name="0003-Don-t-increase-consing_until_gc-when-out-of-memory.patch" Content-Disposition: attachment; filename*0="0003-Don-t-increase-consing_until_gc-when-out-of-memory.patc"; filename*1="h" Content-Transfer-Encoding: quoted-printable >From f4974d6fe6137f436763998be27afafea9866098 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 13 Aug 2019 12:28:53 -0700 Subject: [PATCH 3/3] =3D?UTF-8?q?Don=3DE2=3D80=3D99t=3D20increase=3D20con= sing=3D5Funtil?=3D =3D?UTF-8?q?=3D5Fgc=3D20when=3D20out=3D20of=3D20memory?=3D MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit * src/alloc.c (memory_full): Don=E2=80=99t increase consing_until_gc. Suggested by Eli Zaretskii (Bug#37006#46). --- src/alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/alloc.c b/src/alloc.c index 14b0a7b838..0548a09cb8 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -3866,7 +3866,7 @@ memory_full (size_t nbytes) if (! enough_free_memory) { Vmemory_full =3D Qt; - consing_until_gc =3D memory_full_cons_threshold; + consing_until_gc =3D min (consing_until_gc, memory_full_cons_thres= hold); =20 /* The first time we get here, free the spare memory. */ for (int i =3D 0; i < ARRAYELTS (spare_memory); i++) --=20 2.17.1 --------------4523E105E1821A76D13A372E-- From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 14 Aug 2019 16:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Paul Eggert Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.15657988281218 (code B ref 37006); Wed, 14 Aug 2019 16:08:01 +0000 Received: (at 37006) by debbugs.gnu.org; 14 Aug 2019 16:07:08 +0000 Received: from localhost ([127.0.0.1]:49601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxvno-0000Ja-1m for submit@debbugs.gnu.org; Wed, 14 Aug 2019 12:07:08 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35339) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hxvnm-0000J7-7T for 37006@debbugs.gnu.org; Wed, 14 Aug 2019 12:07:06 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58594) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hxvng-00052Z-HT; Wed, 14 Aug 2019 12:07:00 -0400 Received: from [176.228.60.248] (port=3336 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hxvnf-0005zm-TI; Wed, 14 Aug 2019 12:07:00 -0400 Date: Wed, 14 Aug 2019 19:06:49 +0300 Message-Id: <83v9uzrasm.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@cs.ucla.edu> (message from Paul Eggert on Tue, 13 Aug 2019 12:32:24 -0700) References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> <83wofis508.fsf@gnu.org> <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> <83ef1prly5.fsf@gnu.org> <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org > From: Paul Eggert > Date: Tue, 13 Aug 2019 12:32:24 -0700 > > > OBJECT_CT_MAX should have the value EMACS_INT_MAX. > > Not if EMACS_INT_MAX < INTPTR_MAX, since object counts might overflow in that > case. However, I take your point that consing_until_gc can easily be made to > hold any fixnum value, so I installed the first attached patch. This is to some > extent overkill, since these variables should not be assumed to have this sort > of fine-grained control, but the change is tiny so should be fine. Thanks. However, I'd rather we don't invent new data types unless really necessary. I think we should simply use EMACS_INT (see below), but even if we end up using intptr_max, let's just use that directly, not introduce yet another type which we will have to look up every time we read this code. And likewise with the corresponding _MAX value. Using a non-standard data type makes the code harder to read. > Come to think of it, the limit should be INTMAX_MAX not EMACS_INT_MAX since > gc-cons-threshold could exceed EMACS_INT_MAX. Sorry, I don't think I follow. gc-cons-threshold is a Lisp integer, a fixnum, so it cannot exceed EMACS_INT_MAX, I think. > The idea would be to have a type that is like struct Lisp_Objfwd but with an > extra member, a function to be called whenever the variable is accessed. (Or > perhaps two extra members, a getter and a setter.) This could be useful for > other builtin vars, I suspect. Ah, okay. Can we use for this purpose the existing trapped_write field of Lisp_Symbol that is the base for implementing Lisp watcher functions? > > How else would you succeed in reacting to the change "soon enough"? > > There are other possibilities. We could have a timer, for example. I don't think timers are reliable enough, as they can be deferred for arbitrarily long time interval by some Lisp that takes a long time to finish. > >>> We must also notice the memory-full condition there. > >> > >> memory_full already does that, no? It sets consing_until_gc. > > > > It sets it to a positive value, so no immediate GC will follow. The > > original code was setting the threshold to a very small value, so GC > > would happen immediately. > > Are you talking about the change in commit > 2019-07-20T02:40:03Z!eggert@cs.ucla.edu > (26de2d42d0460c5b193456950a568cb04a29dc00)? If so, I'm not quite following, as > the old code did not GC until consing_since_gc > memory_full_cons_threshold. I > expect that the idea was to not thrash doing GCs when memory is full. With the old code, whenever memory-full was non-nil, and consing_since_gc was more than the size of cons_block (about 1KB on my system), the very next maybe_gc call would actually trigger GC. With the new code, no matter how much consing happened before memory-full became non-nil, we still need to cons 1KB worth of objects before GC happens. This 1KB might be critical when we are out of memory. > Immediate-GC might cause GC thrashing, no? Not sure how, can you elaborate? From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Aug 2019 01:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156583307626865 (code B ref 37006); Thu, 15 Aug 2019 01:38:02 +0000 Received: (at 37006) by debbugs.gnu.org; 15 Aug 2019 01:37:56 +0000 Received: from localhost ([127.0.0.1]:50060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hy4i9-0006yn-MY for submit@debbugs.gnu.org; Wed, 14 Aug 2019 21:37:55 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:45686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hy4i7-0006yR-RR for 37006@debbugs.gnu.org; Wed, 14 Aug 2019 21:37:52 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id F073D1616A8; Wed, 14 Aug 2019 18:37:45 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id jqtD4uWJ5ryN; Wed, 14 Aug 2019 18:37:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 870361626EF; Wed, 14 Aug 2019 18:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bOtED6xe87ZS; Wed, 14 Aug 2019 18:37:44 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 56E441616A8; Wed, 14 Aug 2019 18:37:44 -0700 (PDT) References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> <83wofis508.fsf@gnu.org> <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> <83ef1prly5.fsf@gnu.org> <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@cs.ucla.edu> <83v9uzrasm.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <18886155-d96b-ae07-1df2-1b1d58a8bbb2@cs.ucla.edu> Date: Wed, 14 Aug 2019 18:37:44 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <83v9uzrasm.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii wrote: > However, I'd rather we don't invent new data types unless really > necessary. I did that yesterday, in commit 2019-08-13T19:20:40Z!eggert@cs.ucla.edu (b80559be212292d44ce14ca5e94505cab4d9a868). > gc-cons-threshold is a Lisp integer, a > fixnum, so it cannot exceed EMACS_INT_MAX, I think. No, (setq gc-cons-threshold (1+ most-positive-fixnum)) works and does the right thing. The variable's value can be any intmax_t value. This is useful for quantities like GC object byte counts that might not fit into fixnums. > Can we use for this purpose the existing trapped_write > field of Lisp_Symbol that is the base for implementing Lisp watcher > functions? Don't see why not. > With the old code, whenever memory-full was non-nil, and > consing_since_gc was more than the size of cons_block (about 1KB on my > system), the very next maybe_gc call would actually trigger GC. With > the new code, no matter how much consing happened before memory-full > became non-nil, we still need to cons 1KB worth of objects before GC > happens. This 1KB might be critical when we are out of memory. I don't think the scenario is worth worrying about doing a GC now rather than later. But if we go the trapped_write route, this issue won't matter since the GC will be done quickly. >> Immediate-GC might cause GC thrashing, no? > > Not sure how, can you elaborate? When EMacs is low on memory, if we're not careful Emacs could GC every time maybe_gc is called, which will be roughly equivalent to Emacs hanging and doing nothing. From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Aug 2019 14:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Paul Eggert Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.15658786795262 (code B ref 37006); Thu, 15 Aug 2019 14:18:02 +0000 Received: (at 37006) by debbugs.gnu.org; 15 Aug 2019 14:17:59 +0000 Received: from localhost ([127.0.0.1]:52097 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hyGZi-0001Mo-Sg for submit@debbugs.gnu.org; Thu, 15 Aug 2019 10:17:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41244) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hyGZh-0001Mb-PE for 37006@debbugs.gnu.org; Thu, 15 Aug 2019 10:17:58 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hyGZc-0001Qo-3t; Thu, 15 Aug 2019 10:17:52 -0400 Received: from [176.228.60.248] (port=1039 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hyGZb-0001kD-Hw; Thu, 15 Aug 2019 10:17:51 -0400 Date: Thu, 15 Aug 2019 17:17:43 +0300 Message-Id: <83o90qqzqw.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <18886155-d96b-ae07-1df2-1b1d58a8bbb2@cs.ucla.edu> (message from Paul Eggert on Wed, 14 Aug 2019 18:37:44 -0700) References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> <83wofis508.fsf@gnu.org> <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> <83ef1prly5.fsf@gnu.org> <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@cs.ucla.edu> <83v9uzrasm.fsf@gnu.org> <18886155-d96b-ae07-1df2-1b1d58a8bbb2@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org > From: Paul Eggert > Date: Wed, 14 Aug 2019 18:37:44 -0700 > > > However, I'd rather we don't invent new data types unless really > > necessary. > > I did that yesterday, in commit 2019-08-13T19:20:40Z!eggert@cs.ucla.edu > (b80559be212292d44ce14ca5e94505cab4d9a868). OK, but I still hope we will switch to EMACS_INT instead. > > gc-cons-threshold is a Lisp integer, a > > fixnum, so it cannot exceed EMACS_INT_MAX, I think. > > No, (setq gc-cons-threshold (1+ most-positive-fixnum)) works and does the right > thing. That makes gc-cons-threshold a bignum, right? I don't see why we should support such large values of the threshold, we never did before. most-positive-fixnum on 32-bit systems is large enough for every practical purpose. Also, supporting the full 32 bits (and 64 bits in 64-bit builds) will also allow contradictory situation whereby gc-cons-threshold is higher than what we say should be used to disable GC. > The variable's value can be any intmax_t value. This is useful for > quantities like GC object byte counts that might not fit into fixnums. Why do we need to talk about how many objects are there? GC threshold is not about counting objects, it's about deciding when to GC. > > Can we use for this purpose the existing trapped_write > > field of Lisp_Symbol that is the base for implementing Lisp watcher > > functions? > > Don't see why not. Are you working on that, or should someone else do it? > > With the old code, whenever memory-full was non-nil, and > > consing_since_gc was more than the size of cons_block (about 1KB on my > > system), the very next maybe_gc call would actually trigger GC. With > > the new code, no matter how much consing happened before memory-full > > became non-nil, we still need to cons 1KB worth of objects before GC > > happens. This 1KB might be critical when we are out of memory. > > I don't think the scenario is worth worrying about doing a GC now rather than > later. But if we go the trapped_write route, this issue won't matter since the > GC will be done quickly. I don't think I understand how trapped writes could help in the case of memory-full, since that situation happens independently of setting the value of gc-cons-threshold. > >> Immediate-GC might cause GC thrashing, no? > > > > Not sure how, can you elaborate? > > When EMacs is low on memory, if we're not careful Emacs could GC every time > maybe_gc is called, which will be roughly equivalent to Emacs hanging and doing > nothing. Right, but that's not what I proposed. I proposed to trigger an immediate GC only the first time we detect memory-full. Thereafter, the threshold will be set to 1KB, which should prevent thrashing. From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Aug 2019 18:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156589507616563 (code B ref 37006); Thu, 15 Aug 2019 18:52:02 +0000 Received: (at 37006) by debbugs.gnu.org; 15 Aug 2019 18:51:16 +0000 Received: from localhost ([127.0.0.1]:52437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hyKqC-0004J5-ED for submit@debbugs.gnu.org; Thu, 15 Aug 2019 14:51:16 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:39308) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hyKqA-0004Ip-0m for 37006@debbugs.gnu.org; Thu, 15 Aug 2019 14:51:14 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2CA01161379; Thu, 15 Aug 2019 11:51:08 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id s8RJBkwSk8pI; Thu, 15 Aug 2019 11:51:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id F419516272C; Thu, 15 Aug 2019 11:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DFNVW74VObhC; Thu, 15 Aug 2019 11:51:06 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id C5E92161379; Thu, 15 Aug 2019 11:51:06 -0700 (PDT) References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> <83wofis508.fsf@gnu.org> <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> <83ef1prly5.fsf@gnu.org> <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@cs.ucla.edu> <83v9uzrasm.fsf@gnu.org> <18886155-d96b-ae07-1df2-1b1d58a8bbb2@cs.ucla.edu> <83o90qqzqw.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <58673b86-d27f-c839-2eb6-bd0cbe7a70a5@cs.ucla.edu> Date: Thu, 15 Aug 2019 11:51:06 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <83o90qqzqw.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii wrote: > That makes gc-cons-threshold a bignum, right? If the user sets it to a bignum, yes. Ordinarily it's not. > most-positive-fixnum on 32-bit systems is large enough for > every practical purpose. It's not that hard for the number of consed bytes to exceed most-positive-fixnum on a 32-bit Emacs. Here's a simple test case to illustrate the phenomenon: (let* ((cons-size (car (cdr (car (garbage-collect))))) (long-length (1+ (/ most-positive-fixnum cons-size))) (l (make-list long-length nil))) (cons most-positive-fixnum (* cons-size (length l)))) This yielded (536870911 . 536870912) on the 32-bit Emacs that I just built. Of course a practical application would likely have a bunch of smaller lists, but the same basic idea applies. On such a platform, a user who wants to disable GC while fiddling with a bunch of large lists will need to set gc-cons-threshold to a bignum. > supporting the full 32 bits (and 64 > bits in 64-bit builds) will also allow contradictory situation whereby > gc-cons-threshold is higher than what we say should be used to disable > GC. Sorry, I'm not following. If setting gc-cons-threshold to a large value effectively disables GC, then setting gc-cons-threshold to a larger value should do the same thing. This is independent of any particular large value that we suggest in the manual. >> The variable's value can be any intmax_t value. This is useful for >> quantities like GC object byte counts that might not fit into fixnums. > > Why do we need to talk about how many objects are there? GC threshold > is not about counting objects, it's about deciding when to GC. The GC threshold is part of a related set of integers that count objects and bytes, for use in the returned value of garbage-collect among other things. It's convenient for it to be as least as wide as those other integers, so that calculations involving it do not overflow. >> Don't see why not. > > Are you working on that, or should someone else do it? I can add it to my list of things to do. To my mind, getting the timestamp API nailed down is more urgent, though, because fiddling with GC heuristics doesn't affect the API. > Right, but that's not what I proposed. I proposed to trigger an > immediate GC only the first time we detect memory-full. Thereafter, > the threshold will be set to 1KB, which should prevent thrashing. Isn't it more complicated than that? Emacs can be low on memory, but can then get more and not be low on memory, and then be low on memory again later. From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Aug 2019 19:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Paul Eggert Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156589768521943 (code B ref 37006); Thu, 15 Aug 2019 19:35:01 +0000 Received: (at 37006) by debbugs.gnu.org; 15 Aug 2019 19:34:45 +0000 Received: from localhost ([127.0.0.1]:52475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hyLWG-0005hr-Lq for submit@debbugs.gnu.org; Thu, 15 Aug 2019 15:34:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33466) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hyLWE-0005hb-Im for 37006@debbugs.gnu.org; Thu, 15 Aug 2019 15:34:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53500) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hyLW8-0003Ok-Ld; Thu, 15 Aug 2019 15:34:36 -0400 Received: from [176.228.60.248] (port=4402 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hyLW8-0006fQ-1i; Thu, 15 Aug 2019 15:34:36 -0400 Date: Thu, 15 Aug 2019 22:34:27 +0300 Message-Id: <83mugap6ik.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <58673b86-d27f-c839-2eb6-bd0cbe7a70a5@cs.ucla.edu> (message from Paul Eggert on Thu, 15 Aug 2019 11:51:06 -0700) References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> <83wofis508.fsf@gnu.org> <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> <83ef1prly5.fsf@gnu.org> <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@cs.ucla.edu> <83v9uzrasm.fsf@gnu.org> <18886155-d96b-ae07-1df2-1b1d58a8bbb2@cs.ucla.edu> <83o90qqzqw.fsf@gnu.org> <58673b86-d27f-c839-2eb6-bd0cbe7a70a5@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org > From: Paul Eggert > Date: Thu, 15 Aug 2019 11:51:06 -0700 > > > most-positive-fixnum on 32-bit systems is large enough for > > every practical purpose. > > It's not that hard for the number of consed bytes to exceed most-positive-fixnum > on a 32-bit Emacs. Here's a simple test case to illustrate the phenomenon: > > (let* ((cons-size (car (cdr (car (garbage-collect))))) > (long-length (1+ (/ most-positive-fixnum cons-size))) > (l (make-list long-length nil))) > (cons most-positive-fixnum (* cons-size (length l)))) > > This yielded (536870911 . 536870912) on the 32-bit Emacs that I just built. Of > course a practical application would likely have a bunch of smaller lists, but > the same basic idea applies. On such a platform, a user who wants to disable GC > while fiddling with a bunch of large lists will need to set gc-cons-threshold to > a bignum. I don't see why we must complicate our code to support such a use case. Users who want to disable GC while consing so much object will have to learn that they cannot, not on a 32-bit machine. > > supporting the full 32 bits (and 64 > > bits in 64-bit builds) will also allow contradictory situation whereby > > gc-cons-threshold is higher than what we say should be used to disable > > GC. > > Sorry, I'm not following. If setting gc-cons-threshold to a large value > effectively disables GC, then setting gc-cons-threshold to a larger value should > do the same thing. most-positive-fixnum is infinity for this purpose, and there should not be numbers greater than infinity. It's confusing and hard to explain. > > Why do we need to talk about how many objects are there? GC threshold > > is not about counting objects, it's about deciding when to GC. > > The GC threshold is part of a related set of integers that count objects and > bytes, for use in the returned value of garbage-collect among other things. No, they are just a means to decide when it's a good time to GC. Very large values are used to effectively disable GC, very small values to cause GC "soon". That's all, there are no requirements to count objects or to have any accurate bookeeping of how many objects or bytes were consed. > > Are you working on that, or should someone else do it? > > I can add it to my list of things to do. To my mind, getting the timestamp API > nailed down is more urgent, though, because fiddling with GC heuristics doesn't > affect the API. Well, meanwhile we've broken a very popular use case, so I think fixing this is rather urgent. > > Right, but that's not what I proposed. I proposed to trigger an > > immediate GC only the first time we detect memory-full. Thereafter, > > the threshold will be set to 1KB, which should prevent thrashing. > > Isn't it more complicated than that? Emacs can be low on memory, but can then > get more and not be low on memory, and then be low on memory again later. Maybe so, but we had such code in Emacs for decades. I just want to avoid losing those features. From unknown Fri Jun 13 10:50:12 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Joseph Mingrone Subject: bug#37006: closed (Re: Emacs 27 master consumes more memory than 26 and freezes regularly) Message-ID: References: <9a06837b-eedd-808c-01e8-97ac504032e4@cs.ucla.edu> <86pnlbooyp.fsf@phe.ftfl.ca> X-Gnu-PR-Message: they-closed 37006 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: patch Reply-To: 37006@debbugs.gnu.org Date: Tue, 03 Sep 2019 20:12:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1567541522-1757-1" This is a multi-part message in MIME format... ------------=_1567541522-1757-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #37006: 27.0.50; garbage collection not happening after 26de2d42 which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 37006@debbugs.gnu.org. --=20 37006: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D37006 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1567541522-1757-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 37006-done) by debbugs.gnu.org; 3 Sep 2019 20:11:15 +0000 Received: from localhost ([127.0.0.1]:60570 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i5F90-0000RE-I3 for submit@debbugs.gnu.org; Tue, 03 Sep 2019 16:11:14 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:60720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i5F8w-0000Qw-7I for 37006-done@debbugs.gnu.org; Tue, 03 Sep 2019 16:11:11 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9F3F516008D; Tue, 3 Sep 2019 13:11:04 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id YB2jq8NLSrmE; Tue, 3 Sep 2019 13:11:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 98BD21600AA; Tue, 3 Sep 2019 13:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xJW852S4F1Al; Tue, 3 Sep 2019 13:11:03 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 5F10E16008D; Tue, 3 Sep 2019 13:11:03 -0700 (PDT) Subject: Re: Emacs 27 master consumes more memory than 26 and freezes regularly From: Paul Eggert To: Eli Zaretskii , Akater References: <87mufpfid6.fsf@gmail.com> <83r2518fhz.fsf@gnu.org> Organization: UCLA Computer Science Department Message-ID: <9a06837b-eedd-808c-01e8-97ac504032e4@cs.ucla.edu> Date: Tue, 3 Sep 2019 13:11:03 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------8DA7481FB350B1D4355642B5" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 37006-done Cc: Joseph Mingrone , =?UTF-8?Q?Mattias_Engdeg=c3=a5rd?= , 37006-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------8DA7481FB350B1D4355642B5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Paul Eggert wrote: > Eli Zaretskii wrote: >> once >> gc-cons-threshold is set to a large value, it effectively disables GC >> for the rest of the session, even if after that gc-cons-threshold is >> reset back > > Yes, that's next on my list of things to look at, after untangling this XDG > configuration mess. Although I haven't finished untangling the XDG configuration mess, I did get some time free to attack the gc-cons-threshold issue and installed the attached. As this should fix the problem reported in Bug#37006 I'm boldly closing that bug report. --------------8DA7481FB350B1D4355642B5 Content-Type: text/x-patch; name="0001-Sync-consing_until_gc-with-gc-cons-threshold.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Sync-consing_until_gc-with-gc-cons-threshold.patch" >From 97ffa339b6d67cebcbefbdfaa2880214adab639c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 3 Sep 2019 13:03:34 -0700 Subject: [PATCH] Sync consing_until_gc with gc-cons-threshold Add watchers for gc-cons-threshold and gc-cons-percentage that update consing_until_gc accordingly. Suggested by Eli Zaretskii (Bug#37006#52). * src/alloc.c (consing_threshold, bump_consing_until_gc) (watch_gc_cons_threshold, watch_gc_cons_percentage): New functions. (garbage_collect_1): Use consing_threshold. (syms_of_alloc): Arrange to watch gc-cons-threshold and gc-cons-percentage. --- src/alloc.c | 100 ++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 81 insertions(+), 19 deletions(-) diff --git a/src/alloc.c b/src/alloc.c index 39964c4b29..5f8ef0a5dd 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -5781,6 +5781,68 @@ mark_and_sweep_weak_table_contents (void) } } +/* Return the number of bytes to cons between GCs, assuming + gc-cons-threshold is THRESHOLD and gc-cons-percentage is + GC_CONS_PERCENTAGE. */ +static intmax_t +consing_threshold (intmax_t threshold, Lisp_Object gc_cons_percentage) +{ + if (!NILP (Vmemory_full)) + return memory_full_cons_threshold; + else + { + threshold = max (threshold, GC_DEFAULT_THRESHOLD / 10); + if (FLOATP (gc_cons_percentage)) + { + double tot = (XFLOAT_DATA (gc_cons_percentage) + * total_bytes_of_live_objects ()); + if (threshold < tot) + { + if (tot < INTMAX_MAX) + threshold = tot; + else + threshold = INTMAX_MAX; + } + } + return threshold; + } +} + +/* Increment consing_until_gc by DIFF, avoiding overflow. */ +static Lisp_Object +bump_consing_until_gc (intmax_t diff) +{ + /* If consing_until_gc is negative leave it alone, since this prevents + negative integer overflow and a GC would have been done soon anyway. */ + if (0 <= consing_until_gc + && INT_ADD_WRAPV (consing_until_gc, diff, &consing_until_gc)) + consing_until_gc = INTMAX_MAX; + return Qnil; +} + +/* Watch changes to gc-cons-threshold. */ +static Lisp_Object +watch_gc_cons_threshold (Lisp_Object symbol, Lisp_Object newval, + Lisp_Object operation, Lisp_Object where) +{ + intmax_t new_threshold; + int diff = (INTEGERP (newval) && integer_to_intmax (newval, &new_threshold) + ? (consing_threshold (new_threshold, Vgc_cons_percentage) + - consing_threshold (gc_cons_threshold, Vgc_cons_percentage)) + : 0); + return bump_consing_until_gc (diff); +} + +/* Watch changes to gc-cons-percentage. */ +static Lisp_Object +watch_gc_cons_percentage (Lisp_Object symbol, Lisp_Object newval, + Lisp_Object operation, Lisp_Object where) +{ + int diff = (consing_threshold (consing_until_gc, newval) + - consing_threshold (consing_until_gc, Vgc_cons_percentage)); + return bump_consing_until_gc (diff); +} + /* Subroutine of Fgarbage_collect that does most of the work. */ static bool garbage_collect_1 (struct gcstat *gcst) @@ -5923,25 +5985,8 @@ garbage_collect_1 (struct gcstat *gcst) unblock_input (); - if (!NILP (Vmemory_full)) - consing_until_gc = memory_full_cons_threshold; - else - { - intmax_t threshold = max (gc_cons_threshold, GC_DEFAULT_THRESHOLD / 10); - if (FLOATP (Vgc_cons_percentage)) - { - double tot = (XFLOAT_DATA (Vgc_cons_percentage) - * total_bytes_of_live_objects ()); - if (threshold < tot) - { - if (tot < INTMAX_MAX) - threshold = tot; - else - threshold = INTMAX_MAX; - } - } - consing_until_gc = threshold; - } + consing_until_gc = consing_threshold (gc_cons_threshold, + Vgc_cons_percentage); if (garbage_collection_messages && NILP (Vmemory_full)) { @@ -7362,6 +7407,7 @@ do hash-consing of the objects allocated to pure space. */); DEFSYM (Qheap, "heap"); DEFSYM (QAutomatic_GC, "Automatic GC"); + DEFSYM (Qgc_cons_percentage, "gc-cons-percentage"); DEFSYM (Qgc_cons_threshold, "gc-cons-threshold"); DEFSYM (Qchar_table_extra_slots, "char-table-extra-slots"); @@ -7395,6 +7441,22 @@ N should be nonnegative. */); defsubr (&Smemory_info); defsubr (&Smemory_use_counts); defsubr (&Ssuspicious_object); + + Lisp_Object watcher; + + static union Aligned_Lisp_Subr Swatch_gc_cons_threshold = + {{{ PSEUDOVECTOR_FLAG | (PVEC_SUBR << PSEUDOVECTOR_AREA_BITS) }, + { .a4 = watch_gc_cons_threshold }, + 4, 4, "watch_gc_cons_threshold", 0, 0}}; + XSETSUBR (watcher, &Swatch_gc_cons_threshold.s); + Fadd_variable_watcher (Qgc_cons_threshold, watcher); + + static union Aligned_Lisp_Subr Swatch_gc_cons_percentage = + {{{ PSEUDOVECTOR_FLAG | (PVEC_SUBR << PSEUDOVECTOR_AREA_BITS) }, + { .a4 = watch_gc_cons_percentage }, + 4, 4, "watch_gc_cons_percentage", 0, 0}}; + XSETSUBR (watcher, &Swatch_gc_cons_percentage.s); + Fadd_variable_watcher (Qgc_cons_percentage, watcher); } #ifdef HAVE_X_WINDOWS -- 2.17.1 --------------8DA7481FB350B1D4355642B5-- ------------=_1567541522-1757-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 11 Aug 2019 12:40:14 +0000 Received: from localhost ([127.0.0.1]:44818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwn8v-00038p-Em for submit@debbugs.gnu.org; Sun, 11 Aug 2019 08:40:14 -0400 Received: from lists.gnu.org ([209.51.188.17]:57077) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwn8s-00038c-Bl for submit@debbugs.gnu.org; Sun, 11 Aug 2019 08:40:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60864) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hwn8p-0007o6-FZ for bug-gnu-emacs@gnu.org; Sun, 11 Aug 2019 08:40:10 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hwn8m-0000ZK-By for bug-gnu-emacs@gnu.org; Sun, 11 Aug 2019 08:40:07 -0400 Received: from mail-qt1-x82c.google.com ([2607:f8b0:4864:20::82c]:36717) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hwn8m-0000YT-1k for bug-gnu-emacs@gnu.org; Sun, 11 Aug 2019 08:40:04 -0400 Received: by mail-qt1-x82c.google.com with SMTP id z4so100364117qtc.3 for ; Sun, 11 Aug 2019 05:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftfl.ca; s=google; h=from:to:subject:date:message-id:user-agent:mime-version; bh=fkNShc/A5RRDO8PJbUZW0PSwMjhympNgLFXJcy8igzI=; b=ByhJltx/u0wd+tHtFYBlF33C4VlFt9S5/xgjOF4+b27uZZpPlt4UHMMpp+Xc7r8xYX voyHEBJC8XmubI2PmmlvltMmVuI73EwI4AUTtimoUfi8UzJVEyaNGg8+VaRmNXsSXR9b xQawIxucAmmg/8Ni+3o2v6RIPuFy/XLz/Xk9Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version; bh=fkNShc/A5RRDO8PJbUZW0PSwMjhympNgLFXJcy8igzI=; b=a9q1/B3uqDrHs5A6Bn2wQ6aw+K8qVTCpLahApdai+0hfTyOlCqNacB20/EeCz1c2/n qYHNIMjp+N4FUHx1OclNPqh+Z0BxQ7SI8a4GiUBqQ7R+91ElLfijrR5YEjHQeE05BWqf 4t++RzffhDIWN3oFlkhNnVlUOmuOpxdi9abBGGJbZIzEgx3WxhXI+s/dQ/NqWAQIhjy5 n07l2HtKcf6K62GZiOUyg0BrNnZVhYpwztl7Rv5GEXy4oDAahan6i7T6GRiEdCRZBin0 /Bp8zlhJcWJFjMrb8iaGwlYSGFQffcs0Sojm63UxbYeEipib7VwNW6z+afqNslPRjQxD WNcQ== X-Gm-Message-State: APjAAAU+h0C9Xn3tnzeU71wtj6yTkoUC5ZR51RsMldklzhB7n4pzJCwK FLj0d8vks3b3D1g1JEvr12TbWf+PME0= X-Google-Smtp-Source: APXvYqxS1EhL3mQPLPjlWZPRm2eHwUqReOR2BpQXtDWNGGbQkGxLGENe4VtXEWkIMqd5a/9bjTb6AA== X-Received: by 2002:ac8:2535:: with SMTP id 50mr25702940qtm.373.1565527201535; Sun, 11 Aug 2019 05:40:01 -0700 (PDT) Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-142-167-140-18.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.167.140.18]) by smtp.gmail.com with ESMTPSA id f12sm3795389qkm.18.2019.08.11.05.40.00 for (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sun, 11 Aug 2019 05:40:00 -0700 (PDT) From: Joseph Mingrone To: bug-gnu-emacs@gnu.org Subject: 27.0.50; garbage collection not happening after 26de2d42 Date: Sun, 11 Aug 2019 09:39:58 -0300 Message-ID: <86pnlbooyp.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::82c X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) After 26de2d42 from 2019-06-20, garbage collection is not happening and allocated memory continues to grow until Aug 10 21:39:02 phe kernel: pid 73800 (emacs-27.0.50), uid 1001, was killed: out of swap space and Aug 10 21:39:07 phe kernel: swap_pager_getswapspace(3): failed In GNU Emacs 27.0.50 (build 1, amd64-portbld-freebsd12.0, GTK+ Version 3.24.10) Windowing system distributor 'The X.Org Foundation', version 11.0.11804000 System Description: 12.0-RELEASE-p9 Configured using: 'configure --disable-build-details --localstatedir=/var --with-x --enable-acl --without-cairo --without-dbus --without-gconf --with-gif --with-gnutls --without-gsettings --with-x-toolkit=gtk3 --without-harfbuzz --with-jpeg --with-json --with-file-notification=kqueue --with-lcms2 --with-m17n-flt --with-imagemagick --with-mailutils --with-modules --with-sound=oss --with-libotf --with-png --with-toolkit-scroll-bars --with-rsvg --with-threads --with-tiff --with-xft --with-xim --with-xml2 --with-xpm --without-xwidgets --x-libraries=/usr/local/lib --x-includes=/usr/local/include --prefix=/usr/local --mandir=/usr/local/man --disable-silent-rules --infodir=/usr/local/share/emacs/info/ --build=amd64-portbld-freebsd12.0 'CFLAGS=-O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'CPPFLAGS=-isystem /usr/local/include' 'LDFLAGS= -fstack-protector-strong -L/usr/local/lib '' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GLIB NOTIFY KQUEUE ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS JSON PDUMPER LCMS2 GMP Important settings: value of $LANG: en_CA.UTF-8 locale-coding-system: utf-8-unix Major mode: Message Minor modes in effect: gnus-message-citation-mode: t erc-spelling-mode: t erc-ring-mode: t erc-networks-mode: t erc-netsplit-mode: t erc-menu-mode: t erc-log-mode: t erc-list-mode: t erc-pcomplete-mode: t erc-button-mode: t erc-stamp-mode: t erc-autojoin-mode: t erc-track-mode: t erc-track-minor-mode: t erc-match-mode: t erc-irccontrols-mode: t erc-noncommands-mode: t erc-move-to-prompt-mode: t erc-readonly-mode: t mml-mode: t shell-dirtrack-mode: t flyspell-mode: t global-undo-tree-mode: t undo-tree-mode: t which-key-mode: t show-paren-mode: t savehist-mode: t global-company-mode: t company-mode: t global-auto-revert-mode: t counsel-mode: t ivy-mode: t cl-old-struct-compat-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t visual-line-mode: t transient-mark-mode: t abbrev-mode: t Load-path shadows: /home/jrm/.emacs.d/elpa/slime-20190724.1352/slime-autoloads hides /usr/local/share/emacs/27.0.50/site-lisp/slime/slime-autoloads /home/jrm/.emacs.d/elpa/slime-20190724.1352/slime hides /usr/local/share/emacs/27.0.50/site-lisp/slime/slime /home/jrm/.emacs.d/elpa/slime-20190724.1352/slime-tests hides /usr/local/share/emacs/27.0.50/site-lisp/slime/slime-tests /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-org hides /usr/local/share/emacs/27.0.50/lisp/org/ox-org /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-bibtex hides /usr/local/share/emacs/27.0.50/lisp/org/org-bibtex /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ruby hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ruby /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-table hides /usr/local/share/emacs/27.0.50/lisp/org/ob-table /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-awk hides /usr/local/share/emacs/27.0.50/lisp/org/ob-awk /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-element hides /usr/local/share/emacs/27.0.50/lisp/org/org-element /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ref hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ref /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-processing hides /usr/local/share/emacs/27.0.50/lisp/org/ob-processing /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ditaa hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ditaa /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-info hides /usr/local/share/emacs/27.0.50/lisp/org/org-info /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-md hides /usr/local/share/emacs/27.0.50/lisp/org/ox-md /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-colview hides /usr/local/share/emacs/27.0.50/lisp/org/org-colview /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-mhe hides /usr/local/share/emacs/27.0.50/lisp/org/org-mhe /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-python hides /usr/local/share/emacs/27.0.50/lisp/org/ob-python /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-shell hides /usr/local/share/emacs/27.0.50/lisp/org/ob-shell /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-ascii hides /usr/local/share/emacs/27.0.50/lisp/org/ox-ascii /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-lisp hides /usr/local/share/emacs/27.0.50/lisp/org/ob-lisp /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-capture hides /usr/local/share/emacs/27.0.50/lisp/org/org-capture /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-js hides /usr/local/share/emacs/27.0.50/lisp/org/ob-js /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-src hides /usr/local/share/emacs/27.0.50/lisp/org/org-src /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-sass hides /usr/local/share/emacs/27.0.50/lisp/org/ob-sass /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-footnote hides /usr/local/share/emacs/27.0.50/lisp/org/org-footnote /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-lob hides /usr/local/share/emacs/27.0.50/lisp/org/ob-lob /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-gnus hides /usr/local/share/emacs/27.0.50/lisp/org/org-gnus /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-picolisp hides /usr/local/share/emacs/27.0.50/lisp/org/ob-picolisp /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-scheme hides /usr/local/share/emacs/27.0.50/lisp/org/ob-scheme /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-mobile hides /usr/local/share/emacs/27.0.50/lisp/org/org-mobile /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-latex hides /usr/local/share/emacs/27.0.50/lisp/org/ob-latex /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-crypt hides /usr/local/share/emacs/27.0.50/lisp/org/org-crypt /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-docview hides /usr/local/share/emacs/27.0.50/lisp/org/org-docview /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob hides /usr/local/share/emacs/27.0.50/lisp/org/ob /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-icalendar hides /usr/local/share/emacs/27.0.50/lisp/org/ox-icalendar /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-rmail hides /usr/local/share/emacs/27.0.50/lisp/org/org-rmail /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-publish hides /usr/local/share/emacs/27.0.50/lisp/org/ox-publish /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-sed hides /usr/local/share/emacs/27.0.50/lisp/org/ob-sed /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-datetree hides /usr/local/share/emacs/27.0.50/lisp/org/org-datetree /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-protocol hides /usr/local/share/emacs/27.0.50/lisp/org/org-protocol /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-matlab hides /usr/local/share/emacs/27.0.50/lisp/org/ob-matlab /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-inlinetask hides /usr/local/share/emacs/27.0.50/lisp/org/org-inlinetask /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-shen hides /usr/local/share/emacs/27.0.50/lisp/org/ob-shen /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-core hides /usr/local/share/emacs/27.0.50/lisp/org/ob-core /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-entities hides /usr/local/share/emacs/27.0.50/lisp/org/org-entities /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ebnf hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ebnf /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-coq hides /usr/local/share/emacs/27.0.50/lisp/org/ob-coq /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-forth hides /usr/local/share/emacs/27.0.50/lisp/org/ob-forth /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox hides /usr/local/share/emacs/27.0.50/lisp/org/ox /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-hledger hides /usr/local/share/emacs/27.0.50/lisp/org/ob-hledger /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-abc hides /usr/local/share/emacs/27.0.50/lisp/org/ob-abc /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org hides /usr/local/share/emacs/27.0.50/lisp/org/org /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-archive hides /usr/local/share/emacs/27.0.50/lisp/org/org-archive /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-J hides /usr/local/share/emacs/27.0.50/lisp/org/ob-J /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-macs hides /usr/local/share/emacs/27.0.50/lisp/org/org-macs /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-version hides /usr/local/share/emacs/27.0.50/lisp/org/org-version /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-exp hides /usr/local/share/emacs/27.0.50/lisp/org/ob-exp /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-ctags hides /usr/local/share/emacs/27.0.50/lisp/org/org-ctags /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-java hides /usr/local/share/emacs/27.0.50/lisp/org/ob-java /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-sql hides /usr/local/share/emacs/27.0.50/lisp/org/ob-sql /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-lint hides /usr/local/share/emacs/27.0.50/lisp/org/org-lint /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-keys hides /usr/local/share/emacs/27.0.50/lisp/org/ob-keys /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-eshell hides /usr/local/share/emacs/27.0.50/lisp/org/org-eshell /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-plantuml hides /usr/local/share/emacs/27.0.50/lisp/org/ob-plantuml /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ocaml hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ocaml /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-sqlite hides /usr/local/share/emacs/27.0.50/lisp/org/ob-sqlite /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-list hides /usr/local/share/emacs/27.0.50/lisp/org/org-list /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-lua hides /usr/local/share/emacs/27.0.50/lisp/org/ob-lua /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-C hides /usr/local/share/emacs/27.0.50/lisp/org/ob-C /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-habit hides /usr/local/share/emacs/27.0.50/lisp/org/org-habit /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-bbdb hides /usr/local/share/emacs/27.0.50/lisp/org/org-bbdb /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-lilypond hides /usr/local/share/emacs/27.0.50/lisp/org/ob-lilypond /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-latex hides /usr/local/share/emacs/27.0.50/lisp/org/ox-latex /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-asymptote hides /usr/local/share/emacs/27.0.50/lisp/org/ob-asymptote /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-groovy hides /usr/local/share/emacs/27.0.50/lisp/org/ob-groovy /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-screen hides /usr/local/share/emacs/27.0.50/lisp/org/ob-screen /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-org hides /usr/local/share/emacs/27.0.50/lisp/org/ob-org /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-eww hides /usr/local/share/emacs/27.0.50/lisp/org/org-eww /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-octave hides /usr/local/share/emacs/27.0.50/lisp/org/ob-octave /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-vala hides /usr/local/share/emacs/27.0.50/lisp/org/ob-vala /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-indent hides /usr/local/share/emacs/27.0.50/lisp/org/org-indent /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-macro hides /usr/local/share/emacs/27.0.50/lisp/org/org-macro /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-gnuplot hides /usr/local/share/emacs/27.0.50/lisp/org/ob-gnuplot /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-haskell hides /usr/local/share/emacs/27.0.50/lisp/org/ob-haskell /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-dot hides /usr/local/share/emacs/27.0.50/lisp/org/ob-dot /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-html hides /usr/local/share/emacs/27.0.50/lisp/org/ox-html /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-calc hides /usr/local/share/emacs/27.0.50/lisp/org/ob-calc /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-fortran hides /usr/local/share/emacs/27.0.50/lisp/org/ob-fortran /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-stan hides /usr/local/share/emacs/27.0.50/lisp/org/ob-stan /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-ledger hides /usr/local/share/emacs/27.0.50/lisp/org/ob-ledger /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-io hides /usr/local/share/emacs/27.0.50/lisp/org/ob-io /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-install hides /usr/local/share/emacs/27.0.50/lisp/org/org-install /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-clock hides /usr/local/share/emacs/27.0.50/lisp/org/org-clock /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-agenda hides /usr/local/share/emacs/27.0.50/lisp/org/org-agenda /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-table hides /usr/local/share/emacs/27.0.50/lisp/org/org-table /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-attach hides /usr/local/share/emacs/27.0.50/lisp/org/org-attach /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-faces hides /usr/local/share/emacs/27.0.50/lisp/org/org-faces /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-beamer hides /usr/local/share/emacs/27.0.50/lisp/org/ox-beamer /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-comint hides /usr/local/share/emacs/27.0.50/lisp/org/ob-comint /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-mscgen hides /usr/local/share/emacs/27.0.50/lisp/org/ob-mscgen /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-w3m hides /usr/local/share/emacs/27.0.50/lisp/org/org-w3m /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-maxima hides /usr/local/share/emacs/27.0.50/lisp/org/ob-maxima /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-css hides /usr/local/share/emacs/27.0.50/lisp/org/ob-css /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-compat hides /usr/local/share/emacs/27.0.50/lisp/org/org-compat /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-feed hides /usr/local/share/emacs/27.0.50/lisp/org/org-feed /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-irc hides /usr/local/share/emacs/27.0.50/lisp/org/org-irc /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-clojure hides /usr/local/share/emacs/27.0.50/lisp/org/ob-clojure /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-odt hides /usr/local/share/emacs/27.0.50/lisp/org/ox-odt /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-man hides /usr/local/share/emacs/27.0.50/lisp/org/ox-man /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-emacs-lisp hides /usr/local/share/emacs/27.0.50/lisp/org/ob-emacs-lisp /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-tangle hides /usr/local/share/emacs/27.0.50/lisp/org/ob-tangle /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-R hides /usr/local/share/emacs/27.0.50/lisp/org/ob-R /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-makefile hides /usr/local/share/emacs/27.0.50/lisp/org/ob-makefile /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-duration hides /usr/local/share/emacs/27.0.50/lisp/org/org-duration /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ox-texinfo hides /usr/local/share/emacs/27.0.50/lisp/org/ox-texinfo /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-id hides /usr/local/share/emacs/27.0.50/lisp/org/org-id /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-eval hides /usr/local/share/emacs/27.0.50/lisp/org/ob-eval /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-timer hides /usr/local/share/emacs/27.0.50/lisp/org/org-timer /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-mouse hides /usr/local/share/emacs/27.0.50/lisp/org/org-mouse /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-pcomplete hides /usr/local/share/emacs/27.0.50/lisp/org/org-pcomplete /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-loaddefs hides /usr/local/share/emacs/27.0.50/lisp/org/org-loaddefs /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/org-plot hides /usr/local/share/emacs/27.0.50/lisp/org/org-plot /home/jrm/.emacs.d/elpa/org-plus-contrib-20190805/ob-perl hides /usr/local/share/emacs/27.0.50/lisp/org/ob-perl /home/jrm/.emacs.d/elpa/let-alist-1.0.6/let-alist hides /usr/local/share/emacs/27.0.50/lisp/emacs-lisp/let-alist Features: (shadow emacsbug bbdb-message sendmail nnir bbdb-mua bbdb-com crm sort gnus-cite mail-extr gnus-async gnus-bcklg qp gnus-ml disp-table ace-window cl-print help-fns radix-tree make-mode tramp-cache tramp-sh bookmark mm-archive mule-util url-http url-gw url-cache url-auth url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util finder-inf gnutls network-stream nsm erc-spelling erc-ring erc-networks erc-netsplit erc-menu erc-log erc-list erc-pcomplete erc-button erc-fill erc-stamp erc-join znc warnings erc-track erc-match erc-tex easy-mmode erc-goodies erc erc-backend erc-compat pp erc-loaddefs cl hl-line gnus-topic nndraft nnmh nnagent nnml gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig mailcap nntp gnus-cache gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message rmc puny rfc822 mml mml-sec epa derived epg mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader gnus-win gnus nnheader wid-edit gnus-util rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils text-property-search time-date tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat shell pcomplete parse-time ls-lisp format-spec rx server flyspell ispell undo-tree diff smart-mode-line-dark-theme smart-mode-line rich-minority s pdf-tools-loaddefs misc hydra lv ace-link avy bbdb bbdb-site timezone company-oddmuse company-keywords company-etags etags fileloop generator company-gtags company-dabbrev-code company-dabbrev company-files company-capf company-cmake company-xcode company-clang company-semantic company-eclim company-template company-bbdb which-key paren savehist company edmacro kmacro pcase autorevert filenotify counsel xdg xref project dired dired-loaddefs compile comint ansi-color swiper cl-extra help-mode ivy delsel ring colir color ivy-overlay ffap thingatpt cus-start cus-load benchmark-init benchmark-init-loaddefs tex-site advice slime-autoloads info package easymenu epg-config url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads kqueue lcms2 dynamic-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 4672710 1249112) (symbols 48 33763 2) (strings 32 177500 153301) (string-bytes 1 6559318) (vectors 16 108474) (vector-slots 8 4931122 2331820) (floats 8 565 3210) (intervals 56 12670 13121) (buffers 992 90)) <#secure method=pgpmime mode=sign> ------------=_1567541522-1757-1-- From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: Emacs 27 master consumes more memory than 26 and freezes regularly Resent-From: Joseph Mingrone Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Sep 2019 16:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Paul Eggert Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Eli Zaretskii , Akater , 37006-done@debbugs.gnu.org Received: via spool by 37006-done@debbugs.gnu.org id=D37006.15676999425959 (code D ref 37006); Thu, 05 Sep 2019 16:13:02 +0000 Received: (at 37006-done) by debbugs.gnu.org; 5 Sep 2019 16:12:22 +0000 Received: from localhost ([127.0.0.1]:36047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i5uMv-0001Y1-UX for submit@debbugs.gnu.org; Thu, 05 Sep 2019 12:12:22 -0400 Received: from mail-qt1-f194.google.com ([209.85.160.194]:45275) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i5uMu-0001Xl-59 for 37006-done@debbugs.gnu.org; Thu, 05 Sep 2019 12:12:20 -0400 Received: by mail-qt1-f194.google.com with SMTP id r15so3406916qtn.12 for <37006-done@debbugs.gnu.org>; Thu, 05 Sep 2019 09:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftfl.ca; s=google; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=G8CQVmgY3wAFkvlyfmJh8oVswEzIVQiSMFVYJ5p3XVw=; b=V9RzqOXIeI/ETXAYtlWRzSN5uoagvVElXUcPZD2jJYVlcBfDv8fkWDzg4YecfdxeZe 6gtfw3afDjhJmOVYmFNmfIEN47yX5xeRvDcVfvnV9eZmG40K3P/BHLbXuu7oNyJJCjme EUQTPF2bqteNwCyNr6SDTJKV45M8dwxXgxBSE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=G8CQVmgY3wAFkvlyfmJh8oVswEzIVQiSMFVYJ5p3XVw=; b=R/qOqy3TiGLT7YwoxyW0lEN8IRVPa3HJ9IDrQ8QaknaDrUJXFWo4QLDuNKb6VtN+wG mVnU9ufWqKEofhZiBj6yJUSOiMIjAQ7MfM4T/R9foqSJzwKkUCXjZXPth/a/xWpRUBci L0EdEtGUHHzwVXzqh5Qc5niRk9zRpLqtOB2ORv5y4Fc+nrA2jcwjq+3iwM4NlBbGiNfW m8HDqAkVr2xAaoiWNvXnqDzDZ2Z8fXo1jau0h5FjquwJAzSVgpGZ88RTB9f2Pavsg1k5 HcaMz4snGCvdpMmUN8BPKI63MlM/FBVePd4kbVmnoMbRLoFPxE5YZ+zljdG/rEIWhmp9 +n5Q== X-Gm-Message-State: APjAAAX2T2t+m4lZ3paXD2VAptcS8O1YsbxGsrLCDl0z+T9IPpjdai/F LkYCQ6lYaDrPlVLGjF/osLgttg== X-Google-Smtp-Source: APXvYqwa1w1Ml67Xb4mPEdOzhhYdoVv1EGz+6YeXquuapbJKU/+mu42p0PvKYlA+TLMGKHaj2JoYvA== X-Received: by 2002:a0c:8c8f:: with SMTP id p15mr2269739qvb.57.1567699934441; Thu, 05 Sep 2019 09:12:14 -0700 (PDT) Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-142-167-140-18.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.167.140.18]) by smtp.gmail.com with ESMTPSA id z5sm1310398qki.55.2019.09.05.09.12.12 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 05 Sep 2019 09:12:13 -0700 (PDT) From: Joseph Mingrone References: <87mufpfid6.fsf@gmail.com> <83r2518fhz.fsf@gnu.org> <9a06837b-eedd-808c-01e8-97ac504032e4@cs.ucla.edu> Date: Thu, 05 Sep 2019 13:12:11 -0300 In-Reply-To: <9a06837b-eedd-808c-01e8-97ac504032e4@cs.ucla.edu> (Paul Eggert's message of "Tue, 3 Sep 2019 13:11:03 -0700") Message-ID: <868sr27mec.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Paul Eggert writes: > Paul Eggert wrote: >> Eli Zaretskii wrote: >>> once >>> gc-cons-threshold is set to a large value, it effectively disables GC >>> for the rest of the session, even if after that gc-cons-threshold is >>> reset back >> Yes, that's next on my list of things to look at, after untangling this = XDG=20 >> configuration mess. > Although I haven't finished untangling the XDG configuration mess, I did = get some time free to attack the gc-cons-threshold issue and installed the = attached.=20 > As this should fix the problem reported in Bug#37006 I'm boldly closing t= hat bug report. This issue still exists for me. After rebuilding on 5f089ac, I re-added the (setq gc-cons-threshold most-positive-fixnum) / (setq gc-cons-threshold 800000) surrounding init.el (assuming the issue was fixed) then when Emacs' memory usage was over 2 GB, I turned on `garbage-collection-messages', opened some large files, and could see that garbage collection was not happening. I just removed the surrounding (setq gc-cons-threshold most-positive-fixnum) / (setq gc-cons-threshold 800000) and I see garbage collection is happening for now. I will report back if this does not remain so. In the last week or two running on a commit that was some time after a recent fix (sorry, don't have the exact commit) garbage collection was happening and the memory usage was not exploding. The `gc-cons-threshold' hack in init.el was commented out. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKgBAEBCgCKFiEEVbCTpybDiFVxIrrVNqQMg7DW754FAl1xM9tfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDU1 QjA5M0E3MjZDMzg4NTU3MTIyQkFENTM2QTQwQzgzQjBENkVGOUUMHGpybUBmdGZs LmNhAAoJEDakDIOw1u+eqywQAKDXi+Ic4EvaUB2y5Ux/TukF5mu+Iv6cCTWmofxj pM8H6b5sbWWSonLmjNh4XN230J4dEPNr4syaodj9UDWiyf88HvUhnUJPXI5HzTS/ 08cdLLXJXHWEYhaYA5K50kJUjotkt6KNwa/MNb7QJltTpzSNa05+XQnfxIslKT3S hbQmfR7Un73t1JpdvTEYgXXd0JBiBuhviZp81mij8K3ReoES8aMbtnABVZ3Nmq6a L9YRWEkn5h40YsWOIiHJoWKF2cqII+l1Sdi07r6Lw3r0kj3hWLCW81clNRfNbZmK U7B5BFVLYed7CeGYvQgZNSPGPSDWS8OtBYTyLY2ShzUodywNoOfXZKIvkFsMGkPu iB1j5M+OMWKvQf1ekwVG1wWvBSOgp5SM04EU+BvGG4y6/RAf6MmnKdWNDEQxMGWD UMMFm8GZUqGCdjKhOriOxYZ+xExsoQiuuVl4OmTjWG7OL71PKpv6MAB5cKWcLvAj Wc/1ZSmlbcRlpujThn7piSOGd2eFg47KAN1yjuY/Ivcre9e3VIKD7Dh8khrNg0i5 /VJLegC2H89iSqJQVEmIjhLRdbhoWKbL0ElrAUt33OvLT3vQQ7T+E/ofYcL2pyyx 52ja8HUDSQ7IKUzDOgsxrRhkN6Tdv6SRWGToBPd4f+bXVPNMp892jf0W1I7jTLIF W8jG =5Wm0 -----END PGP SIGNATURE----- --=-=-=-- From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: Emacs 27 master consumes more memory than 26 and freezes regularly Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Sep 2019 17:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Joseph Mingrone Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Eli Zaretskii , 37006@debbugs.gnu.org, Akater Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156770289511184 (code B ref 37006); Thu, 05 Sep 2019 17:02:02 +0000 Received: (at 37006) by debbugs.gnu.org; 5 Sep 2019 17:01:35 +0000 Received: from localhost ([127.0.0.1]:36070 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i5v8Z-0002uK-0b for submit@debbugs.gnu.org; Thu, 05 Sep 2019 13:01:35 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i5v8X-0002u5-EX for 37006@debbugs.gnu.org; Thu, 05 Sep 2019 13:01:33 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 168CB160211; Thu, 5 Sep 2019 10:01:28 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 4_KRLsbgzASB; Thu, 5 Sep 2019 10:01:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4B0861601BF; Thu, 5 Sep 2019 10:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id l0THZyMoYkSM; Thu, 5 Sep 2019 10:01:27 -0700 (PDT) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 27F5F160101; Thu, 5 Sep 2019 10:01:27 -0700 (PDT) References: <87mufpfid6.fsf@gmail.com> <83r2518fhz.fsf@gnu.org> <9a06837b-eedd-808c-01e8-97ac504032e4@cs.ucla.edu> <868sr27mec.fsf@phe.ftfl.ca> From: Paul Eggert Openpgp: preference=signencrypt Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBfgQTAQIAKAUCTIByZAIbAwUJEswDAAYLCQgHAwIG FQgCCQoLBBYCAwECHgECF4AACgkQ7ZfpDmKqfjRRGw/+Ij03dhYfYl/gXVRiuzV1gGrbHk+t nfrI/C7fAeoFzQ5tVgVinShaPkZo0HTPf18x6IDEdAiO8Mqo1yp0CtHmzGMCJ50o4Grgfjlr 6g/+vtEOKbhleszN2XpJvpwM2QgGvn/laTLUu8PH9aRWTs7qJJZKKKAb4sxYc92FehPu6FOD 0dDiyhlDAq4lOV2mdBpzQbiojoZzQLMQwjpgCTK2572eK9EOEQySUThXrSIz6ASenp4NYTFH s9tuJQvXk9gZDdPSl3bp+47dGxlxEWLpBIM7zIONw4ks4azgT8nvDZxA5IZHtvqBlJLBObYY 0Le61Wp0y3TlBDh2qdK8eYL426W4scEMSuig5gb8OAtQiBW6k2sGUxxeiv8ovWu8YAZgKJfu oWI+uRnMEddruY8JsoM54KaKvZikkKs2bg1ndtLVzHpJ6qFZC7QVjeHUh6/BmgvdjWPZYFTt N+KA9CWX3GQKKgN3uu988yznD7LnB98T4EUH1HA/GnfBqMV1gpzTvPc4qVQinCmIkEFp83zl +G5fCjJJ3W7ivzCnYo4KhKLpFUm97okTKR2LW3xZzEW4cLSWO387MTK3CzDOx5qe6s4a91Zu ZM/j/TQdTLDaqNn83kA4Hq48UHXYxcIh+Nd8k/3w6lFuoK0wrOFiywjLx+0ur5jmmbecBGHc 1xdhAFHOwU0ETIByZAEQAKaF678T9wyH4wjTrV1Pz3cDEoSnV/0ZUrOT37p1dcGyj/IXq1x6 70HRVahAmk0sZpYc25PF9D5GPYHFWlNjuPU96rDndXB3hedmBRhLdC4bAXjI4DV+bmdVe+q/ IMnlZRaVlm9EiMCVAR6w13sReu7qXkW9r3RwY2AzXskp/tAe4BRKr1Zmbvi2nbnQ6epEC42r Rbx0B1EhjbIQZ5JHGk24iPT7LdBgnNmos5wYjzwNlkMQD5T0Ydzhk7J+UxwA5m46mOhRDC2r FV/A0gm5TLy8DXjv/Esc4gYnYai6SQqnUEVh5LuV8YCJBnijs+Tiw71x1icmn6xGI45EugJO gec+rLypYgpVp4x0HI5T88qBRYCkxH3Kg8Qo+EWNA9A4LRQ9DX8njona0gf0s03tocK8kBN6 6UoqqPtHBnc4eMgBymCflK12eKfd2YYxnyg9cZazWA5VslvTxpm76hbg5oiAEH/Vg/8MxHyA nPhfrgwyPrmJEcVBafdspJnYQxBYNco2LFPIhlOvWh8r4at+s+M3Lb26oUTczlgdW1Sf3SDA 77BMRnF0FQyE+7AzV79MBN4ykiqaezQxtaF1Fy/tvkhffSo8u+dwG0EgJh+te38gTcISVr0G IPplLz6YhjrbHrPRF1CN5UuL9DBGjxuN35RLNVEfta6RUFlR6NctTjvrABEBAAHCwWUEGAEC AA8FAkyAcmQCGwwFCRLMAwAACgkQ7ZfpDmKqfjSrHA/+KzAKvTxRhA9MWNLxIyJ7S5uJ16gs T3oCjZrBKGEhKMOGX4O0GA6VOEryO7QRCCYah3oxSG38IAnNeiwJXgU9Bzkk85UGbPEd7HGF /VSeHCQwWou6jqUDTSDvn9YhNTdG0KXPM74aC+xr2Zow1O2mhXihgWKD0Dw+0LYPnUOsQ0KO FxHXXYHmRrS1OZPU59BLvc+TRhIhafSHKLwbXK+6ckkxBx6h8z5ccpG0Qs4bFhdFYnFrEieD LoGmnE2YLhdV6swJ9VNCS6pLiEohT3fm7aXm15tZOIyzMZhHRSAPblXxQ0ZSWjq8oRrcYNFx c4W1URpAkBCOYJoXvQfD5L3lqAl8TCqDUzYxhH/tJhbDdHrqHH767jaDaTB1+Talp/2AMKwc XNOdiklGxbmHVG6YGl6g8Lrbsu9NZEI4yLlHzuikthJWgz+3vZhVGyNlt+HNIoF6CjDL2omu 5cEq4RDHM44QqPk6l7O0pUvN1mT4B+S1b08RKpqm/ff015E37HNV/piIvJlxGAYz8PSfuGCB 1thMYqlmgdhd9/BabGFbGGYHA6U4/T5zqU+f6xHy1SsAQZ1MSKlLwekBIT+4/cLRGqCHjnV0 q5H/T6a7t5mPkbzSrOLSo4puj+IToNjYyYIDBWzhlA19avOa+rvUjmHtD3sFN7cXWtkGoi8b uNcby4U= Organization: UCLA Computer Science Department Message-ID: Date: Thu, 5 Sep 2019 10:01:26 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <868sr27mec.fsf@phe.ftfl.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 9/5/19 9:12 AM, Joseph Mingrone wrote: >> As this should fix the problem reported in Bug#37006 I'm boldly closing that bug report. > This issue still exists for me. After rebuilding on 5f089ac, I re-added > the (setq gc-cons-threshold most-positive-fixnum) / (setq > gc-cons-threshold 800000) surrounding init.el (assuming the issue was > fixed) then when Emacs' memory usage was over 2 GB, I turned on > `garbage-collection-messages', opened some large files, and could see > that garbage collection was not happening. OK, reopening the bug report. I take it that all I need to do is to modify init.el as mentioned above, and then edit some large files. I'll take a look at that. From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: Emacs 27 master consumes more memory than 26 and freezes regularly Resent-From: Joseph Mingrone Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Sep 2019 17:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Paul Eggert Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Eli Zaretskii , 37006@debbugs.gnu.org, Akater Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156770317411660 (code B ref 37006); Thu, 05 Sep 2019 17:07:01 +0000 Received: (at 37006) by debbugs.gnu.org; 5 Sep 2019 17:06:14 +0000 Received: from localhost ([127.0.0.1]:36074 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i5vD3-00031z-US for submit@debbugs.gnu.org; Thu, 05 Sep 2019 13:06:14 -0400 Received: from mail-qt1-f170.google.com ([209.85.160.170]:38087) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i5vD3-00031m-07 for 37006@debbugs.gnu.org; Thu, 05 Sep 2019 13:06:13 -0400 Received: by mail-qt1-f170.google.com with SMTP id b2so3662815qtq.5 for <37006@debbugs.gnu.org>; Thu, 05 Sep 2019 10:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftfl.ca; s=google; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=qg2N4GD9a5ruubB994JZxWnIhywlVWfDcCLUpSij/U0=; b=bWWPmqJMNGJeFkvOyOBn0z+YDRsP+jusrhgq/0uzuMFwFZILryHd8T2U7W96/ayuVE cq+RO8ZiT1sEAp0t55PEa0XErxfBlAEs7qRLGVwBfqLbHoiBUfjsZlSSZZ66R2iG/IW0 bUf0ipfJ0/VldSydqQzPNQ/gVdQTl336eeMsk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=qg2N4GD9a5ruubB994JZxWnIhywlVWfDcCLUpSij/U0=; b=rMxkERdvcurJzFsBsvckU+E0JM0wVwVaA7O1evfeUGBAdladv3ituqjdcxXDHr5eLV 6qF85NbjQBkTig6ooEXZ0YtKsePAPvi4Qugfsi3b/3xdfE/XpswLi/Gex079gTdzH1ug wh0MzKzExYr9oi65Ep2414qf7VzEsJphXr/XrPUlHuG8yjLmzI/kRxwdpVYxUH5LTO8p 3KSJHrqDSdgdKLBv2mrXqdee6Xaap3qd0H1tS+P/kwd5hzuafGWojQnDzE5UDeXByTwv m4f+6oHgEctXWd9oVIHUXf7xxTTvOI78K7d3bKp+7JNfk9BfMTMjaLdt8OQZuCurtg5/ pJMg== X-Gm-Message-State: APjAAAX6Ra0oMuoTGsTXpHPd6oPr2ZI2UBvO2vos/nRvv8+iOuipdKLR n0GKCoQhVAuI67I/cirpH+460Q== X-Google-Smtp-Source: APXvYqw5gLoSL6ZEVfXMdDYd4hCfZu1N4E2R81DSeQVBhQuBEulIfgcaqt1rfzzuaod8CTx9Y12sSA== X-Received: by 2002:ac8:6b45:: with SMTP id x5mr4448906qts.205.1567703167361; Thu, 05 Sep 2019 10:06:07 -0700 (PDT) Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-142-167-140-18.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.167.140.18]) by smtp.gmail.com with ESMTPSA id a23sm1173492qtj.5.2019.09.05.10.06.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 05 Sep 2019 10:06:06 -0700 (PDT) From: Joseph Mingrone References: <87mufpfid6.fsf@gmail.com> <83r2518fhz.fsf@gnu.org> <9a06837b-eedd-808c-01e8-97ac504032e4@cs.ucla.edu> <868sr27mec.fsf@phe.ftfl.ca> Date: Thu, 05 Sep 2019 14:06:03 -0300 In-Reply-To: (Paul Eggert's message of "Thu, 5 Sep 2019 10:01:26 -0700") Message-ID: <861rwu7jwk.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Paul Eggert writes: > On 9/5/19 9:12 AM, Joseph Mingrone wrote: >>> As this should fix the problem reported in Bug#37006 I'm boldly closing= that bug report. >> This issue still exists for me. After rebuilding on 5f089ac, I re-added >> the (setq gc-cons-threshold most-positive-fixnum) / (setq >> gc-cons-threshold 800000) surrounding init.el (assuming the issue was >> fixed) then when Emacs' memory usage was over 2 GB, I turned on >> `garbage-collection-messages', opened some large files, and could see >> that garbage collection was not happening. > OK, reopening the bug report. I take it that all I need to do is to modif= y init.el as mentioned above, and then edit some large files. I'll=20 > take a look at that. That's all I had to do (on a FreeBSD 12.0 system). I can give you an account a FreeBSD system if that is helpful and saves you some time. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKgBAEBCgCKFiEEVbCTpybDiFVxIrrVNqQMg7DW754FAl1xQHxfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDU1 QjA5M0E3MjZDMzg4NTU3MTIyQkFENTM2QTQwQzgzQjBENkVGOUUMHGpybUBmdGZs LmNhAAoJEDakDIOw1u+ehyUP/jILfmM8Lnmtx2e45EWAed6eXuE4hQBMbniIn+pG hG6U6CDD/Rpm4YmdjjUWxS6sg2uxZnS48bWO/s6Zkh60VQ50DoUBigk+W3cTPGTi +jmnawovaR5Nsd2d2PJVfYm7ok5tjObAuDQtf5VAnvCVZbG7tGru3H0S9h60uC3A bXV8HeSIKtBTe36U91wE8C/LYB2trpGwChVj2wpPNLfP9iDjqBRNpBuYg8O/C5wo zXNIEflQpielnPV+Mlmq4nvgNbY9AqlQ1fI1duk1P+j9mwnZpyU4ArxDB5dPOlPv pq2s8f1dBbebyp6of9Dv2ejWipK5T6//IasQnQPCiR+dTmEUJqeQDGApS/I7gFkU Kl+ruMg2mo7EFLYsj6sqdh6YyrOsaHH/frmzUWnX37Ao3ie3fegl0677obBaPnzU /Fb4OS1r/2n0DEdq817VXnDLQGyUFe9KaYJQLc7G5gZofXqVwt320JQ2bVBjiL3x U2hs3IK20b/BdhKqJuUqPtCEUO185WzUKO4CoQuEC2+5vt15byEJhIhstLRxPsTJ SnGnapjar8s5CVjWY6nFJ2RSqjdfNNzcUAdW4ZxIkpiLYXVmGBahwqc9z20uS5Lh gXjR9N26l9cfKnaw5bcQnIFCBBfJ9rT+Hc3JvS0BRtwkZr42AO9h3C9ynW+mGo/x zC3k =Y8NR -----END PGP SIGNATURE----- --=-=-=-- From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: Emacs 27 master consumes more memory than 26 and freezes regularly Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Sep 2019 20:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Joseph Mingrone Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Eli Zaretskii , 37006@debbugs.gnu.org, Akater Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156771542917773 (code B ref 37006); Thu, 05 Sep 2019 20:31:01 +0000 Received: (at 37006) by debbugs.gnu.org; 5 Sep 2019 20:30:29 +0000 Received: from localhost ([127.0.0.1]:36129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i5yOi-0004ca-P0 for submit@debbugs.gnu.org; Thu, 05 Sep 2019 16:30:29 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:47434) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i5yOf-0004cJ-Cb for 37006@debbugs.gnu.org; Thu, 05 Sep 2019 16:30:26 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 83CC5160101; Thu, 5 Sep 2019 13:30:19 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id sYUiljOX3lFg; Thu, 5 Sep 2019 13:30:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 933091601EE; Thu, 5 Sep 2019 13:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rHFHyHrmlVY2; Thu, 5 Sep 2019 13:30:18 -0700 (PDT) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 71FA3160101; Thu, 5 Sep 2019 13:30:18 -0700 (PDT) From: Paul Eggert References: <87mufpfid6.fsf@gmail.com> <83r2518fhz.fsf@gnu.org> <9a06837b-eedd-808c-01e8-97ac504032e4@cs.ucla.edu> <868sr27mec.fsf@phe.ftfl.ca> Openpgp: preference=signencrypt Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBfgQTAQIAKAUCTIByZAIbAwUJEswDAAYLCQgHAwIG FQgCCQoLBBYCAwECHgECF4AACgkQ7ZfpDmKqfjRRGw/+Ij03dhYfYl/gXVRiuzV1gGrbHk+t nfrI/C7fAeoFzQ5tVgVinShaPkZo0HTPf18x6IDEdAiO8Mqo1yp0CtHmzGMCJ50o4Grgfjlr 6g/+vtEOKbhleszN2XpJvpwM2QgGvn/laTLUu8PH9aRWTs7qJJZKKKAb4sxYc92FehPu6FOD 0dDiyhlDAq4lOV2mdBpzQbiojoZzQLMQwjpgCTK2572eK9EOEQySUThXrSIz6ASenp4NYTFH s9tuJQvXk9gZDdPSl3bp+47dGxlxEWLpBIM7zIONw4ks4azgT8nvDZxA5IZHtvqBlJLBObYY 0Le61Wp0y3TlBDh2qdK8eYL426W4scEMSuig5gb8OAtQiBW6k2sGUxxeiv8ovWu8YAZgKJfu oWI+uRnMEddruY8JsoM54KaKvZikkKs2bg1ndtLVzHpJ6qFZC7QVjeHUh6/BmgvdjWPZYFTt N+KA9CWX3GQKKgN3uu988yznD7LnB98T4EUH1HA/GnfBqMV1gpzTvPc4qVQinCmIkEFp83zl +G5fCjJJ3W7ivzCnYo4KhKLpFUm97okTKR2LW3xZzEW4cLSWO387MTK3CzDOx5qe6s4a91Zu ZM/j/TQdTLDaqNn83kA4Hq48UHXYxcIh+Nd8k/3w6lFuoK0wrOFiywjLx+0ur5jmmbecBGHc 1xdhAFHOwU0ETIByZAEQAKaF678T9wyH4wjTrV1Pz3cDEoSnV/0ZUrOT37p1dcGyj/IXq1x6 70HRVahAmk0sZpYc25PF9D5GPYHFWlNjuPU96rDndXB3hedmBRhLdC4bAXjI4DV+bmdVe+q/ IMnlZRaVlm9EiMCVAR6w13sReu7qXkW9r3RwY2AzXskp/tAe4BRKr1Zmbvi2nbnQ6epEC42r Rbx0B1EhjbIQZ5JHGk24iPT7LdBgnNmos5wYjzwNlkMQD5T0Ydzhk7J+UxwA5m46mOhRDC2r FV/A0gm5TLy8DXjv/Esc4gYnYai6SQqnUEVh5LuV8YCJBnijs+Tiw71x1icmn6xGI45EugJO gec+rLypYgpVp4x0HI5T88qBRYCkxH3Kg8Qo+EWNA9A4LRQ9DX8njona0gf0s03tocK8kBN6 6UoqqPtHBnc4eMgBymCflK12eKfd2YYxnyg9cZazWA5VslvTxpm76hbg5oiAEH/Vg/8MxHyA nPhfrgwyPrmJEcVBafdspJnYQxBYNco2LFPIhlOvWh8r4at+s+M3Lb26oUTczlgdW1Sf3SDA 77BMRnF0FQyE+7AzV79MBN4ykiqaezQxtaF1Fy/tvkhffSo8u+dwG0EgJh+te38gTcISVr0G IPplLz6YhjrbHrPRF1CN5UuL9DBGjxuN35RLNVEfta6RUFlR6NctTjvrABEBAAHCwWUEGAEC AA8FAkyAcmQCGwwFCRLMAwAACgkQ7ZfpDmKqfjSrHA/+KzAKvTxRhA9MWNLxIyJ7S5uJ16gs T3oCjZrBKGEhKMOGX4O0GA6VOEryO7QRCCYah3oxSG38IAnNeiwJXgU9Bzkk85UGbPEd7HGF /VSeHCQwWou6jqUDTSDvn9YhNTdG0KXPM74aC+xr2Zow1O2mhXihgWKD0Dw+0LYPnUOsQ0KO FxHXXYHmRrS1OZPU59BLvc+TRhIhafSHKLwbXK+6ckkxBx6h8z5ccpG0Qs4bFhdFYnFrEieD LoGmnE2YLhdV6swJ9VNCS6pLiEohT3fm7aXm15tZOIyzMZhHRSAPblXxQ0ZSWjq8oRrcYNFx c4W1URpAkBCOYJoXvQfD5L3lqAl8TCqDUzYxhH/tJhbDdHrqHH767jaDaTB1+Talp/2AMKwc XNOdiklGxbmHVG6YGl6g8Lrbsu9NZEI4yLlHzuikthJWgz+3vZhVGyNlt+HNIoF6CjDL2omu 5cEq4RDHM44QqPk6l7O0pUvN1mT4B+S1b08RKpqm/ff015E37HNV/piIvJlxGAYz8PSfuGCB 1thMYqlmgdhd9/BabGFbGGYHA6U4/T5zqU+f6xHy1SsAQZ1MSKlLwekBIT+4/cLRGqCHjnV0 q5H/T6a7t5mPkbzSrOLSo4puj+IToNjYyYIDBWzhlA19avOa+rvUjmHtD3sFN7cXWtkGoi8b uNcby4U= Organization: UCLA Computer Science Department Message-ID: <6e982f57-2755-b746-d0de-c73ebcfcd6ac@cs.ucla.edu> Date: Thu, 5 Sep 2019 13:30:18 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------79FDA849815286DF67E1D7FF" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------79FDA849815286DF67E1D7FF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I reproduced the problem on Fedora 30 x86-64 and installed the attached fix. Please give it a try. --------------79FDA849815286DF67E1D7FF Content-Type: text/x-patch; name="0001-Fix-bugs-when-recalculating-consing_until_gc.patch" Content-Disposition: attachment; filename="0001-Fix-bugs-when-recalculating-consing_until_gc.patch" Content-Transfer-Encoding: quoted-printable >From 2c246fde5ebe76bf48322c09fd685e48c0737f2a Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 5 Sep 2019 13:25:43 -0700 Subject: [PATCH] Fix bugs when recalculating consing_until_gc MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit Problem reported by Joseph Mingrone (Bug#37006#72). * src/alloc.c (watch_gc_cons_threshold) (watch_gc_cons_percentage): Don=E2=80=99t try to store an intmax_t into an int. Redo to make the code clearer. (watch_gc_cons_percentage): Use gc_cons_threshold, not consing_until_gc. --- src/alloc.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/src/alloc.c b/src/alloc.c index 089f61f833..5fc515f33b 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -5783,18 +5783,18 @@ mark_and_sweep_weak_table_contents (void) =20 /* Return the number of bytes to cons between GCs, assuming gc-cons-threshold is THRESHOLD and gc-cons-percentage is - GC_CONS_PERCENTAGE. */ + PERCENTAGE. */ static intmax_t -consing_threshold (intmax_t threshold, Lisp_Object gc_cons_percentage) +consing_threshold (intmax_t threshold, Lisp_Object percentage) { if (!NILP (Vmemory_full)) return memory_full_cons_threshold; else { threshold =3D max (threshold, GC_DEFAULT_THRESHOLD / 10); - if (FLOATP (gc_cons_percentage)) + if (FLOATP (percentage)) { - double tot =3D (XFLOAT_DATA (gc_cons_percentage) + double tot =3D (XFLOAT_DATA (percentage) * total_bytes_of_live_objects ()); if (threshold < tot) { @@ -5825,11 +5825,12 @@ bump_consing_until_gc (intmax_t diff) watch_gc_cons_threshold (Lisp_Object symbol, Lisp_Object newval, Lisp_Object operation, Lisp_Object where) { - intmax_t new_threshold; - int diff =3D (INTEGERP (newval) && integer_to_intmax (newval, &new_thr= eshold) - ? (consing_threshold (new_threshold, Vgc_cons_percentage) - - consing_threshold (gc_cons_threshold, Vgc_cons_percentage)) - : 0); + Lisp_Object percentage =3D Vgc_cons_percentage; + intmax_t threshold; + intmax_t diff =3D (INTEGERP (newval) && integer_to_intmax (newval, &th= reshold) + ? (consing_threshold (threshold, percentage) + - consing_threshold (gc_cons_threshold, percentage)) + : 0); return bump_consing_until_gc (diff); } =20 @@ -5838,8 +5839,9 @@ watch_gc_cons_threshold (Lisp_Object symbol, Lisp_O= bject newval, watch_gc_cons_percentage (Lisp_Object symbol, Lisp_Object newval, Lisp_Object operation, Lisp_Object where) { - int diff =3D (consing_threshold (consing_until_gc, newval) - - consing_threshold (consing_until_gc, Vgc_cons_percentage)); + intmax_t threshold =3D gc_cons_threshold; + intmax_t diff =3D (consing_threshold (threshold, newval) + - consing_threshold (threshold, Vgc_cons_percentage)); return bump_consing_until_gc (diff); } =20 --=20 2.21.0 --------------79FDA849815286DF67E1D7FF-- From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: Emacs 27 master consumes more memory than 26 and freezes regularly Resent-From: Joseph Mingrone Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Sep 2019 21:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Paul Eggert Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Eli Zaretskii , 37006@debbugs.gnu.org, Akater Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156771894531657 (code B ref 37006); Thu, 05 Sep 2019 21:30:02 +0000 Received: (at 37006) by debbugs.gnu.org; 5 Sep 2019 21:29:05 +0000 Received: from localhost ([127.0.0.1]:36155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i5zJQ-0008EW-QV for submit@debbugs.gnu.org; Thu, 05 Sep 2019 17:29:05 -0400 Received: from mail-qk1-f178.google.com ([209.85.222.178]:35599) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i5zJP-0008E0-70 for 37006@debbugs.gnu.org; Thu, 05 Sep 2019 17:29:03 -0400 Received: by mail-qk1-f178.google.com with SMTP id d26so3718112qkk.2 for <37006@debbugs.gnu.org>; Thu, 05 Sep 2019 14:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftfl.ca; s=google; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=JWfCYaRfSVteGzA3NlYOUSSw56szV1+qZxhLKa3D8ko=; b=MVGfkkc823ptwcvfmVv8iSfgW7CU7YEA1lpozOd9YZERMampwpNYjDoZ72ThhCwTvI sVF/0bSe9epxnkO4s1o6gB+ecWix6HMR6UiVXq8pKdkBNuXXWNl5fl5YhjrMnfvePftY Y+EI4Jvt+A4tNTd1OkVpG0lOBB9tnTQlKtYa0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=JWfCYaRfSVteGzA3NlYOUSSw56szV1+qZxhLKa3D8ko=; b=VdfkZuKIKymp7U6MtsCo0opeDvwc+NfVMh2S2O69FXpoxzAutGUk+A0eXHRG5byuwX R/JJfxhOdlPs+OPiSgS7YWl5/j4ltP25hv7zLswVF7SspV6iuzOWmY3/DLvNvTS3UeaO uSmqQLTtv920PgLvIUlRB4hdDHSvoaD60+kZN0IocNTpS1z2dGOhfitMwam0aS3G0rAJ otR+I/mggrvktOwCHXL7JLEUobb1BQWCm1hDa393ZgGIW3ScwPZft6P8Wan8pWDAtbn/ IR/laVLdvxFWO9xkUFenW5+qJi5ti8QQ4FttRJwSspMOw5I0RBnpCAmMgBlCrp7AawDv lzRA== X-Gm-Message-State: APjAAAV+oNknHx/BS+5vJkD7XLwBE3tgbXcHVRfmeiXn+ee7rV/zgnkN CrlSFXFdU1F9dGwhIs3nrRHSGw== X-Google-Smtp-Source: APXvYqxJJQcFEKLccbEA0Q8kygcBbor0EC7CJZXK1fY4GF+mN06dLb5gUYeCQfWcpMuECUQbJwLWyA== X-Received: by 2002:a37:a1d5:: with SMTP id k204mr4920865qke.242.1567718937529; Thu, 05 Sep 2019 14:28:57 -0700 (PDT) Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-142-167-140-18.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.167.140.18]) by smtp.gmail.com with ESMTPSA id 13sm1548103qkc.81.2019.09.05.14.28.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 05 Sep 2019 14:28:56 -0700 (PDT) From: Joseph Mingrone References: <87mufpfid6.fsf@gmail.com> <83r2518fhz.fsf@gnu.org> <9a06837b-eedd-808c-01e8-97ac504032e4@cs.ucla.edu> <868sr27mec.fsf@phe.ftfl.ca> <6e982f57-2755-b746-d0de-c73ebcfcd6ac@cs.ucla.edu> Date: Thu, 05 Sep 2019 18:28:53 -0300 In-Reply-To: <6e982f57-2755-b746-d0de-c73ebcfcd6ac@cs.ucla.edu> (Paul Eggert's message of "Thu, 5 Sep 2019 13:30:18 -0700") Message-ID: <8636hajuui.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Paul Eggert writes: > I reproduced the problem on Fedora 30 x86-64 and installed the attached fix. Please give it a try. Hello Paul, I see lots of garbage collection messages after a few minutes, so it seems to be working. If garbage collection stops after Emacs has been running longer, I'll report back. Thank you, Joseph --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKgBAEBCgCKFiEEVbCTpybDiFVxIrrVNqQMg7DW754FAl1xfhVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDU1 QjA5M0E3MjZDMzg4NTU3MTIyQkFENTM2QTQwQzgzQjBENkVGOUUMHGpybUBmdGZs LmNhAAoJEDakDIOw1u+eTTQP/2BZKy4qGcfuMvzvuF+i6v41PtaTTvRF912DLpye qYz8NF0849jb31sHUlNMYbWXVdwZlI6yVIY1BIjc5blmLkaX9u7QjJ0g1Y/Ogfq2 hR5LxYj7dBAiIn1sJugh6LSVvbAa9El1zCzHVRPW/Bjq3hRlrSfCxpaHxZpRwhIP Cmn7ZM9zgR0rXYbzRT7Wfd6x1Oez8mX5VSxl76a7jOTiORhZe3z/8GMysZcAfHw4 Uh/MJopX9ME2DWAr2MsBnABTrdCw4pUDwwIX03MQeLrLTZfmHUmr2LoICvEh9USt HRHKJxBR+YHUja6655BuT1go9YFJuH6juPpBRH6WLQkKuSQvpo027gitjKzXM7m7 PUrJern+jIPCJ0ePxFvyKRYAoaccwwS71KabAa3I+zUhCipQtiQwB6bBvN+LpdqL VZ7WWNSDgYoN9Kb6vldIo4Omt/pKvaXGO/rEnmRt6XWfbkrEs5F31TT+b6m7GNoW H5qaX4P3zeqSSsvOLNZt6ZoHglTkLsQSRt0e5HYJmm9RiJpcjiGLFt/1EINCz5Qs 9LNOw9oYy5BAtrbsY9EJykC+dGcyabIQQpCwRbqvPlw2X+0VHG68bfKweGQ+xBld yPi8QduEjlcRQ16w9HeTk+SZAGo1OGQTrW5zg0SyH7W1dG1QcPrPSObh/3oeKoib 74lr =B31N -----END PGP SIGNATURE----- --=-=-=-- From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: Emacs 27 master consumes more memory than 26 and freezes regularly Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Sep 2019 21:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Joseph Mingrone Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Eli Zaretskii , 37006@debbugs.gnu.org, Akater Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156771930432413 (code B ref 37006); Thu, 05 Sep 2019 21:36:01 +0000 Received: (at 37006) by debbugs.gnu.org; 5 Sep 2019 21:35:04 +0000 Received: from localhost ([127.0.0.1]:36168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i5zPD-0008Qj-Rs for submit@debbugs.gnu.org; Thu, 05 Sep 2019 17:35:04 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58512) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i5zPC-0008Q9-OB for 37006@debbugs.gnu.org; Thu, 05 Sep 2019 17:35:03 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2E30F1601EE; Thu, 5 Sep 2019 14:34:57 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Cm_PWfBnbte9; Thu, 5 Sep 2019 14:34:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7991D160172; Thu, 5 Sep 2019 14:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CGWUMe3cvU81; Thu, 5 Sep 2019 14:34:56 -0700 (PDT) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 591A71601EE; Thu, 5 Sep 2019 14:34:56 -0700 (PDT) References: <87mufpfid6.fsf@gmail.com> <83r2518fhz.fsf@gnu.org> <9a06837b-eedd-808c-01e8-97ac504032e4@cs.ucla.edu> <868sr27mec.fsf@phe.ftfl.ca> <6e982f57-2755-b746-d0de-c73ebcfcd6ac@cs.ucla.edu> <8636hajuui.fsf@phe.ftfl.ca> From: Paul Eggert Openpgp: preference=signencrypt Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBfgQTAQIAKAUCTIByZAIbAwUJEswDAAYLCQgHAwIG FQgCCQoLBBYCAwECHgECF4AACgkQ7ZfpDmKqfjRRGw/+Ij03dhYfYl/gXVRiuzV1gGrbHk+t nfrI/C7fAeoFzQ5tVgVinShaPkZo0HTPf18x6IDEdAiO8Mqo1yp0CtHmzGMCJ50o4Grgfjlr 6g/+vtEOKbhleszN2XpJvpwM2QgGvn/laTLUu8PH9aRWTs7qJJZKKKAb4sxYc92FehPu6FOD 0dDiyhlDAq4lOV2mdBpzQbiojoZzQLMQwjpgCTK2572eK9EOEQySUThXrSIz6ASenp4NYTFH s9tuJQvXk9gZDdPSl3bp+47dGxlxEWLpBIM7zIONw4ks4azgT8nvDZxA5IZHtvqBlJLBObYY 0Le61Wp0y3TlBDh2qdK8eYL426W4scEMSuig5gb8OAtQiBW6k2sGUxxeiv8ovWu8YAZgKJfu oWI+uRnMEddruY8JsoM54KaKvZikkKs2bg1ndtLVzHpJ6qFZC7QVjeHUh6/BmgvdjWPZYFTt N+KA9CWX3GQKKgN3uu988yznD7LnB98T4EUH1HA/GnfBqMV1gpzTvPc4qVQinCmIkEFp83zl +G5fCjJJ3W7ivzCnYo4KhKLpFUm97okTKR2LW3xZzEW4cLSWO387MTK3CzDOx5qe6s4a91Zu ZM/j/TQdTLDaqNn83kA4Hq48UHXYxcIh+Nd8k/3w6lFuoK0wrOFiywjLx+0ur5jmmbecBGHc 1xdhAFHOwU0ETIByZAEQAKaF678T9wyH4wjTrV1Pz3cDEoSnV/0ZUrOT37p1dcGyj/IXq1x6 70HRVahAmk0sZpYc25PF9D5GPYHFWlNjuPU96rDndXB3hedmBRhLdC4bAXjI4DV+bmdVe+q/ IMnlZRaVlm9EiMCVAR6w13sReu7qXkW9r3RwY2AzXskp/tAe4BRKr1Zmbvi2nbnQ6epEC42r Rbx0B1EhjbIQZ5JHGk24iPT7LdBgnNmos5wYjzwNlkMQD5T0Ydzhk7J+UxwA5m46mOhRDC2r FV/A0gm5TLy8DXjv/Esc4gYnYai6SQqnUEVh5LuV8YCJBnijs+Tiw71x1icmn6xGI45EugJO gec+rLypYgpVp4x0HI5T88qBRYCkxH3Kg8Qo+EWNA9A4LRQ9DX8njona0gf0s03tocK8kBN6 6UoqqPtHBnc4eMgBymCflK12eKfd2YYxnyg9cZazWA5VslvTxpm76hbg5oiAEH/Vg/8MxHyA nPhfrgwyPrmJEcVBafdspJnYQxBYNco2LFPIhlOvWh8r4at+s+M3Lb26oUTczlgdW1Sf3SDA 77BMRnF0FQyE+7AzV79MBN4ykiqaezQxtaF1Fy/tvkhffSo8u+dwG0EgJh+te38gTcISVr0G IPplLz6YhjrbHrPRF1CN5UuL9DBGjxuN35RLNVEfta6RUFlR6NctTjvrABEBAAHCwWUEGAEC AA8FAkyAcmQCGwwFCRLMAwAACgkQ7ZfpDmKqfjSrHA/+KzAKvTxRhA9MWNLxIyJ7S5uJ16gs T3oCjZrBKGEhKMOGX4O0GA6VOEryO7QRCCYah3oxSG38IAnNeiwJXgU9Bzkk85UGbPEd7HGF /VSeHCQwWou6jqUDTSDvn9YhNTdG0KXPM74aC+xr2Zow1O2mhXihgWKD0Dw+0LYPnUOsQ0KO FxHXXYHmRrS1OZPU59BLvc+TRhIhafSHKLwbXK+6ckkxBx6h8z5ccpG0Qs4bFhdFYnFrEieD LoGmnE2YLhdV6swJ9VNCS6pLiEohT3fm7aXm15tZOIyzMZhHRSAPblXxQ0ZSWjq8oRrcYNFx c4W1URpAkBCOYJoXvQfD5L3lqAl8TCqDUzYxhH/tJhbDdHrqHH767jaDaTB1+Talp/2AMKwc XNOdiklGxbmHVG6YGl6g8Lrbsu9NZEI4yLlHzuikthJWgz+3vZhVGyNlt+HNIoF6CjDL2omu 5cEq4RDHM44QqPk6l7O0pUvN1mT4B+S1b08RKpqm/ff015E37HNV/piIvJlxGAYz8PSfuGCB 1thMYqlmgdhd9/BabGFbGGYHA6U4/T5zqU+f6xHy1SsAQZ1MSKlLwekBIT+4/cLRGqCHjnV0 q5H/T6a7t5mPkbzSrOLSo4puj+IToNjYyYIDBWzhlA19avOa+rvUjmHtD3sFN7cXWtkGoi8b uNcby4U= Organization: UCLA Computer Science Department Message-ID: Date: Thu, 5 Sep 2019 14:34:56 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <8636hajuui.fsf@phe.ftfl.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 9/5/19 2:28 PM, Joseph Mingrone wrote: > I see lots of garbage collection messages after a few minutes, so it > seems to be working. If garbage collection stops after Emacs has been > running longer, I'll report back. Thanks for checking. I'll close the bug report (again :-). If the bug reappears I can reopen it again. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 05 17:35:14 2019 Received: (at control) by debbugs.gnu.org; 5 Sep 2019 21:35:14 +0000 Received: from localhost ([127.0.0.1]:36171 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i5zPO-0008RC-4M for submit@debbugs.gnu.org; Thu, 05 Sep 2019 17:35:14 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58660) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i5zPK-0008Qr-7r for control@debbugs.gnu.org; Thu, 05 Sep 2019 17:35:13 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E2FB5160172 for ; Thu, 5 Sep 2019 14:35:04 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id g8w8Il0jXKHC for ; Thu, 5 Sep 2019 14:35:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 46F7516019B for ; Thu, 5 Sep 2019 14:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sdOcc2kkxzUt for ; Thu, 5 Sep 2019 14:35:04 -0700 (PDT) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 2AD35160172 for ; Thu, 5 Sep 2019 14:35:04 -0700 (PDT) To: GNU bug control From: Paul Eggert Subject: close 37006 Openpgp: preference=signencrypt Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBfgQTAQIAKAUCTIByZAIbAwUJEswDAAYLCQgHAwIG FQgCCQoLBBYCAwECHgECF4AACgkQ7ZfpDmKqfjRRGw/+Ij03dhYfYl/gXVRiuzV1gGrbHk+t nfrI/C7fAeoFzQ5tVgVinShaPkZo0HTPf18x6IDEdAiO8Mqo1yp0CtHmzGMCJ50o4Grgfjlr 6g/+vtEOKbhleszN2XpJvpwM2QgGvn/laTLUu8PH9aRWTs7qJJZKKKAb4sxYc92FehPu6FOD 0dDiyhlDAq4lOV2mdBpzQbiojoZzQLMQwjpgCTK2572eK9EOEQySUThXrSIz6ASenp4NYTFH s9tuJQvXk9gZDdPSl3bp+47dGxlxEWLpBIM7zIONw4ks4azgT8nvDZxA5IZHtvqBlJLBObYY 0Le61Wp0y3TlBDh2qdK8eYL426W4scEMSuig5gb8OAtQiBW6k2sGUxxeiv8ovWu8YAZgKJfu oWI+uRnMEddruY8JsoM54KaKvZikkKs2bg1ndtLVzHpJ6qFZC7QVjeHUh6/BmgvdjWPZYFTt N+KA9CWX3GQKKgN3uu988yznD7LnB98T4EUH1HA/GnfBqMV1gpzTvPc4qVQinCmIkEFp83zl +G5fCjJJ3W7ivzCnYo4KhKLpFUm97okTKR2LW3xZzEW4cLSWO387MTK3CzDOx5qe6s4a91Zu ZM/j/TQdTLDaqNn83kA4Hq48UHXYxcIh+Nd8k/3w6lFuoK0wrOFiywjLx+0ur5jmmbecBGHc 1xdhAFHOwU0ETIByZAEQAKaF678T9wyH4wjTrV1Pz3cDEoSnV/0ZUrOT37p1dcGyj/IXq1x6 70HRVahAmk0sZpYc25PF9D5GPYHFWlNjuPU96rDndXB3hedmBRhLdC4bAXjI4DV+bmdVe+q/ IMnlZRaVlm9EiMCVAR6w13sReu7qXkW9r3RwY2AzXskp/tAe4BRKr1Zmbvi2nbnQ6epEC42r Rbx0B1EhjbIQZ5JHGk24iPT7LdBgnNmos5wYjzwNlkMQD5T0Ydzhk7J+UxwA5m46mOhRDC2r FV/A0gm5TLy8DXjv/Esc4gYnYai6SQqnUEVh5LuV8YCJBnijs+Tiw71x1icmn6xGI45EugJO gec+rLypYgpVp4x0HI5T88qBRYCkxH3Kg8Qo+EWNA9A4LRQ9DX8njona0gf0s03tocK8kBN6 6UoqqPtHBnc4eMgBymCflK12eKfd2YYxnyg9cZazWA5VslvTxpm76hbg5oiAEH/Vg/8MxHyA nPhfrgwyPrmJEcVBafdspJnYQxBYNco2LFPIhlOvWh8r4at+s+M3Lb26oUTczlgdW1Sf3SDA 77BMRnF0FQyE+7AzV79MBN4ykiqaezQxtaF1Fy/tvkhffSo8u+dwG0EgJh+te38gTcISVr0G IPplLz6YhjrbHrPRF1CN5UuL9DBGjxuN35RLNVEfta6RUFlR6NctTjvrABEBAAHCwWUEGAEC AA8FAkyAcmQCGwwFCRLMAwAACgkQ7ZfpDmKqfjSrHA/+KzAKvTxRhA9MWNLxIyJ7S5uJ16gs T3oCjZrBKGEhKMOGX4O0GA6VOEryO7QRCCYah3oxSG38IAnNeiwJXgU9Bzkk85UGbPEd7HGF /VSeHCQwWou6jqUDTSDvn9YhNTdG0KXPM74aC+xr2Zow1O2mhXihgWKD0Dw+0LYPnUOsQ0KO FxHXXYHmRrS1OZPU59BLvc+TRhIhafSHKLwbXK+6ckkxBx6h8z5ccpG0Qs4bFhdFYnFrEieD LoGmnE2YLhdV6swJ9VNCS6pLiEohT3fm7aXm15tZOIyzMZhHRSAPblXxQ0ZSWjq8oRrcYNFx c4W1URpAkBCOYJoXvQfD5L3lqAl8TCqDUzYxhH/tJhbDdHrqHH767jaDaTB1+Talp/2AMKwc XNOdiklGxbmHVG6YGl6g8Lrbsu9NZEI4yLlHzuikthJWgz+3vZhVGyNlt+HNIoF6CjDL2omu 5cEq4RDHM44QqPk6l7O0pUvN1mT4B+S1b08RKpqm/ff015E37HNV/piIvJlxGAYz8PSfuGCB 1thMYqlmgdhd9/BabGFbGGYHA6U4/T5zqU+f6xHy1SsAQZ1MSKlLwekBIT+4/cLRGqCHjnV0 q5H/T6a7t5mPkbzSrOLSo4puj+IToNjYyYIDBWzhlA19avOa+rvUjmHtD3sFN7cXWtkGoi8b uNcby4U= Organization: UCLA Computer Science Department Message-ID: Date: Thu, 5 Sep 2019 14:35:04 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 37006 From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: Emacs 27 master consumes more memory than 26 and freezes regularly Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Sep 2019 07:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Paul Eggert Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org, nuclearspace@gmail.com Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156775343615176 (code B ref 37006); Fri, 06 Sep 2019 07:04:02 +0000 Received: (at 37006) by debbugs.gnu.org; 6 Sep 2019 07:03:56 +0000 Received: from localhost ([127.0.0.1]:36361 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i68Hj-0003wh-S8 for submit@debbugs.gnu.org; Fri, 06 Sep 2019 03:03:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46307) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i68Hh-0003w3-MJ for 37006@debbugs.gnu.org; Fri, 06 Sep 2019 03:03:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51188) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i68Hb-00038u-Jg; Fri, 06 Sep 2019 03:03:47 -0400 Received: from [176.228.60.248] (port=2309 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i68Hb-0004VX-3E; Fri, 06 Sep 2019 03:03:47 -0400 Date: Fri, 06 Sep 2019 10:03:45 +0300 Message-Id: <837e6l7vou.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Paul Eggert on Thu, 5 Sep 2019 14:34:56 -0700) References: <87mufpfid6.fsf@gmail.com> <83r2518fhz.fsf@gnu.org> <9a06837b-eedd-808c-01e8-97ac504032e4@cs.ucla.edu> <868sr27mec.fsf@phe.ftfl.ca> <6e982f57-2755-b746-d0de-c73ebcfcd6ac@cs.ucla.edu> <8636hajuui.fsf@phe.ftfl.ca> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Eli Zaretskii , Akater , > 37006@debbugs.gnu.org, Mattias Engdegård > From: Paul Eggert > Date: Thu, 5 Sep 2019 14:34:56 -0700 > > On 9/5/19 2:28 PM, Joseph Mingrone wrote: > > > I see lots of garbage collection messages after a few minutes, so it > > seems to be working. If garbage collection stops after Emacs has been > > running longer, I'll report back. > > Thanks for checking. I'll close the bug report (again :-). If the bug > reappears I can reopen it again. Thanks for fixing the bug. I wonder if it would make sense to have a simple test for this particular use case, as this seems to be quite a popular technique these days in users' init files. The test would do the sequence of GC settings like the one which triggered this bug, and then verify that GC happens after it when expected. WDYT? From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Sep 2019 07:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.156844748928730 (code B ref 37006); Sat, 14 Sep 2019 07:52:02 +0000 Received: (at 37006) by debbugs.gnu.org; 14 Sep 2019 07:51:29 +0000 Received: from localhost ([127.0.0.1]:45807 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i92q9-0007TJ-4Y for submit@debbugs.gnu.org; Sat, 14 Sep 2019 03:51:29 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:56718) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i92q6-0007T3-1p for 37006@debbugs.gnu.org; Sat, 14 Sep 2019 03:51:27 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5A8301601EE; Sat, 14 Sep 2019 00:51:20 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id P0-SyMoqbXSG; Sat, 14 Sep 2019 00:51:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DCE3C16021D; Sat, 14 Sep 2019 00:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KSZztKKhX2l6; Sat, 14 Sep 2019 00:51:18 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 9BB4F1601EE; Sat, 14 Sep 2019 00:51:18 -0700 (PDT) References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> <83wofis508.fsf@gnu.org> <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> <83ef1prly5.fsf@gnu.org> <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@cs.ucla.edu> <83v9uzrasm.fsf@gnu.org> <18886155-d96b-ae07-1df2-1b1d58a8bbb2@cs.ucla.edu> <83o90qqzqw.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Sat, 14 Sep 2019 00:51:18 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <83o90qqzqw.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------AE78A0F38C0C63807462A40B" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------AE78A0F38C0C63807462A40B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/15/19 7:17 AM, Eli Zaretskii wrote: > OK, but I still hope we will switch to EMACS_INT instead. I installed the attached patch into master, and it changes the relevant threshold variables to EMACS_INT, as part of a somewhat-larger cleanup. This should make a practical difference only on 32-bit Emacs without --with-wide-int. --------------AE78A0F38C0C63807462A40B Content-Type: text/x-patch; name="0001-Improve-gc-cons-percentage-calculation.patch" Content-Disposition: attachment; filename="0001-Improve-gc-cons-percentage-calculation.patch" Content-Transfer-Encoding: quoted-printable >From bac66302e92bdd3a353102d2076548e7e83d92e5 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 14 Sep 2019 00:32:01 -0700 Subject: [PATCH] Improve gc-cons-percentage calculation MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit The old calculation relied on a hodgpodge of partly updated GC stats to find a number to multiply gc-cons-percentage by. The new one counts data found by the previous GC, plus half of the data allocated since then; this is more systematic albeit still ad hoc. * src/alloc.c (consing_until_gc, gc_threshold, consing_threshold): Now EMACS_INT, not intmax_t. (HI_THRESHOLD): New macro. (tally_consing): New function. (make_interval, allocate_string, allocate_string_data) (make_float, free_cons, allocate_vectorlike, Fmake_symbol): Use it. (allow_garbage_collection, inhibit_garbage_collection) (consing_threshold, garbage_collect): Use HI_THRESHOLD rather than INTMAX_MAX. (consing_threshold): New arg SINCE_GC. All callers changed. (bump_consing_until_gc): Return new consing_until_gc, instead of nil. All callers changed. Don=E2=80=99t worry about overflow since we now saturate at HI_THRESHOLD. Guess that half of recently-allocated objects are still alive, instead of relying on the previous (even less-accurate) hodgepodge. (maybe_garbage_collect): New function. (garbage_collect): Work even if a finalizer disables or enables memory profiling. Do not use malloc_probe if GC reclaimed nothing. * src/lisp.h (maybe_gc): Call maybe_garbage_collect instead of garbage_collect. --- src/alloc.c | 127 ++++++++++++++++++++++++++++++---------------------- src/lisp.h | 5 ++- 2 files changed, 77 insertions(+), 55 deletions(-) diff --git a/src/alloc.c b/src/alloc.c index ca8311cc00..497f600551 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -224,7 +224,7 @@ struct emacs_globals globals; =20 /* maybe_gc collects garbage if this goes negative. */ =20 -intmax_t consing_until_gc; +EMACS_INT consing_until_gc; =20 #ifdef HAVE_PDUMPER /* Number of finalizers run: used to loop over GC until we stop @@ -238,9 +238,16 @@ bool gc_in_progress; =20 /* System byte and object counts reported by GC. */ =20 +/* Assume byte counts fit in uintptr_t and object counts fit into + intptr_t. */ typedef uintptr_t byte_ct; typedef intptr_t object_ct; =20 +/* Large-magnitude value for a threshold count, which fits in EMACS_INT. + Using only half the EMACS_INT range avoids overflow hassles. + There is no need to fit these counts into fixnums. */ +#define HI_THRESHOLD (EMACS_INT_MAX / 2) + /* Number of live and free conses etc. counted by the most-recent GC. *= / =20 static struct gcstat @@ -299,7 +306,7 @@ static intptr_t garbage_collection_inhibited; =20 /* The GC threshold in bytes, the last time it was calculated from gc-cons-threshold and gc-cons-percentage. */ -static intmax_t gc_threshold; +static EMACS_INT gc_threshold; =20 /* If nonzero, this is a warning delivered by malloc and not yet displayed. */ @@ -536,6 +543,15 @@ XFLOAT_INIT (Lisp_Object f, double n) XFLOAT (f)->u.data =3D n; } =20 +/* Account for allocation of NBYTES in the heap. This is a separate + function to avoid hassles with implementation-defined conversion + from unsigned to signed types. */ +static void +tally_consing (ptrdiff_t nbytes) +{ + consing_until_gc -=3D nbytes; +} + #ifdef DOUG_LEA_MALLOC static bool pointers_fit_in_lispobj_p (void) @@ -1372,7 +1388,7 @@ make_interval (void) =20 MALLOC_UNBLOCK_INPUT; =20 - consing_until_gc -=3D sizeof (struct interval); + tally_consing (sizeof (struct interval)); intervals_consed++; RESET_INTERVAL (val); val->gcmarkbit =3D 0; @@ -1739,7 +1755,7 @@ allocate_string (void) MALLOC_UNBLOCK_INPUT; =20 ++strings_consed; - consing_until_gc -=3D sizeof *s; + tally_consing (sizeof *s); =20 #ifdef GC_CHECK_STRING_BYTES if (!noninteractive) @@ -1859,7 +1875,7 @@ allocate_string_data (struct Lisp_String *s, old_data->string =3D NULL; } =20 - consing_until_gc -=3D needed; + tally_consing (needed); } =20 =20 @@ -2464,7 +2480,7 @@ make_float (double float_value) =20 XFLOAT_INIT (val, float_value); eassert (!XFLOAT_MARKED_P (XFLOAT (val))); - consing_until_gc -=3D sizeof (struct Lisp_Float); + tally_consing (sizeof (struct Lisp_Float)); floats_consed++; return val; } @@ -2535,8 +2551,8 @@ free_cons (struct Lisp_Cons *ptr) ptr->u.s.u.chain =3D cons_free_list; ptr->u.s.car =3D dead_object (); cons_free_list =3D ptr; - if (INT_ADD_WRAPV (consing_until_gc, sizeof *ptr, &consing_until_gc)) - consing_until_gc =3D INTMAX_MAX; + ptrdiff_t nbytes =3D sizeof *ptr; + tally_consing (-nbytes); } =20 DEFUN ("cons", Fcons, Scons, 2, 2, 0, @@ -3153,7 +3169,7 @@ allocate_vectorlike (ptrdiff_t len) if (find_suspicious_object_in_range (p, (char *) p + nbytes)) emacs_abort (); =20 - consing_until_gc -=3D nbytes; + tally_consing (nbytes); vector_cells_consed +=3D len; =20 MALLOC_UNBLOCK_INPUT; @@ -3438,7 +3454,7 @@ Its value is void, and its function definition and = property list are nil. */) MALLOC_UNBLOCK_INPUT; =20 init_symbol (val, name); - consing_until_gc -=3D sizeof (struct Lisp_Symbol); + tally_consing (sizeof (struct Lisp_Symbol)); symbols_consed++; return val; } @@ -5477,7 +5493,7 @@ staticpro (Lisp_Object const *varaddress) static void allow_garbage_collection (intmax_t consing) { - consing_until_gc =3D consing - (INTMAX_MAX - consing_until_gc); + consing_until_gc =3D consing - (HI_THRESHOLD - consing_until_gc); garbage_collection_inhibited--; } =20 @@ -5487,7 +5503,7 @@ inhibit_garbage_collection (void) ptrdiff_t count =3D SPECPDL_INDEX (); record_unwind_protect_intmax (allow_garbage_collection, consing_until_= gc); garbage_collection_inhibited++; - consing_until_gc =3D INTMAX_MAX; + consing_until_gc =3D HI_THRESHOLD; return count; } =20 @@ -5761,11 +5777,13 @@ mark_and_sweep_weak_table_contents (void) } } =20 -/* Return the number of bytes to cons between GCs, assuming - gc-cons-threshold is THRESHOLD and gc-cons-percentage is - PERCENTAGE. */ -static intmax_t -consing_threshold (intmax_t threshold, Lisp_Object percentage) +/* Return the number of bytes to cons between GCs, given THRESHOLD and + PERCENTAGE. When calculating a threshold based on PERCENTAGE, + assume SINCE_GC bytes have been allocated since the most recent GC. + The returned value is positive and no greater than HI_THRESHOLD. */ +static EMACS_INT +consing_threshold (intmax_t threshold, Lisp_Object percentage, + intmax_t since_gc) { if (!NILP (Vmemory_full)) return memory_full_cons_threshold; @@ -5775,42 +5793,33 @@ consing_threshold (intmax_t threshold, Lisp_Objec= t percentage) if (FLOATP (percentage)) { double tot =3D (XFLOAT_DATA (percentage) - * total_bytes_of_live_objects ()); + * (total_bytes_of_live_objects () + since_gc)); if (threshold < tot) { - if (tot < INTMAX_MAX) - threshold =3D tot; + if (tot < HI_THRESHOLD) + return tot; else - threshold =3D INTMAX_MAX; + return HI_THRESHOLD; } } - return threshold; + return min (threshold, HI_THRESHOLD); } } =20 -/* Adjust consing_until_gc, assuming gc-cons-threshold is THRESHOLD and - gc-cons-percentage is PERCENTAGE. */ -static Lisp_Object +/* Adjust consing_until_gc and gc_threshold, given THRESHOLD and PERCENT= AGE. + Return the updated consing_until_gc. */ + +static EMACS_INT bump_consing_until_gc (intmax_t threshold, Lisp_Object percentage) { - /* If consing_until_gc is negative leave it alone, since this prevents - negative integer overflow and a GC would have been done soon anyway= . */ - if (0 <=3D consing_until_gc) - { - threshold =3D consing_threshold (threshold, percentage); - intmax_t sum; - if (INT_ADD_WRAPV (consing_until_gc, threshold - gc_threshold, &su= m)) - { - /* Scale the threshold down so that consing_until_gc does - not overflow. */ - sum =3D INTMAX_MAX; - threshold =3D INTMAX_MAX - consing_until_gc + gc_threshold; - } - consing_until_gc =3D sum; - gc_threshold =3D threshold; - } - - return Qnil; + /* Guesstimate that half the bytes allocated since the most + recent GC are still in use. */ + EMACS_INT since_gc =3D (gc_threshold - consing_until_gc) >> 1; + EMACS_INT new_gc_threshold =3D consing_threshold (threshold, percentag= e, + since_gc); + consing_until_gc +=3D new_gc_threshold - gc_threshold; + gc_threshold =3D new_gc_threshold; + return consing_until_gc; } =20 /* Watch changes to gc-cons-threshold. */ @@ -5821,7 +5830,8 @@ watch_gc_cons_threshold (Lisp_Object symbol, Lisp_O= bject newval, intmax_t threshold; if (! (INTEGERP (newval) && integer_to_intmax (newval, &threshold))) return Qnil; - return bump_consing_until_gc (threshold, Vgc_cons_percentage); + bump_consing_until_gc (threshold, Vgc_cons_percentage); + return Qnil; } =20 /* Watch changes to gc-cons-percentage. */ @@ -5829,7 +5839,18 @@ static Lisp_Object watch_gc_cons_percentage (Lisp_Object symbol, Lisp_Object newval, Lisp_Object operation, Lisp_Object where) { - return bump_consing_until_gc (gc_cons_threshold, newval); + bump_consing_until_gc (gc_cons_threshold, newval); + return Qnil; +} + +/* It may be time to collect garbage. Recalculate consing_until_gc, + since it might depend on current usage, and do the garbage + collection if the recalculation says so. */ +void +maybe_garbage_collect (void) +{ + if (bump_consing_until_gc (gc_cons_threshold, Vgc_cons_percentage) < 0= ) + garbage_collect (); } =20 /* Subroutine of Fgarbage_collect that does most of the work. */ @@ -5841,7 +5862,6 @@ garbage_collect (void) bool message_p; ptrdiff_t count =3D SPECPDL_INDEX (); struct timespec start; - byte_ct tot_before =3D 0; =20 eassert (weak_hash_tables =3D=3D NULL); =20 @@ -5856,14 +5876,15 @@ garbage_collect (void) FOR_EACH_BUFFER (nextb) compact_buffer (nextb); =20 - if (profiler_memory_running) - tot_before =3D total_bytes_of_live_objects (); + byte_ct tot_before =3D (profiler_memory_running + ? total_bytes_of_live_objects () + : (byte_ct) -1); =20 start =3D current_timespec (); =20 /* In case user calls debug_print during GC, don't let that cause a recursive GC. */ - consing_until_gc =3D INTMAX_MAX; + consing_until_gc =3D HI_THRESHOLD; =20 /* Save what's currently displayed in the echo area. Don't do that if we are GC'ing because we've run out of memory, since @@ -5975,7 +5996,7 @@ garbage_collect (void) unblock_input (); =20 consing_until_gc =3D gc_threshold - =3D consing_threshold (gc_cons_threshold, Vgc_cons_percentage); + =3D consing_threshold (gc_cons_threshold, Vgc_cons_percentage, 0); =20 if (garbage_collection_messages && NILP (Vmemory_full)) { @@ -6008,11 +6029,11 @@ garbage_collect (void) gcs_done++; =20 /* Collect profiling data. */ - if (profiler_memory_running) + if (tot_before !=3D (byte_ct) -1) { byte_ct tot_after =3D total_bytes_of_live_objects (); - byte_ct swept =3D tot_before <=3D tot_after ? 0 : tot_before - tot= _after; - malloc_probe (min (swept, SIZE_MAX)); + if (tot_after < tot_before) + malloc_probe (min (tot_before - tot_after, SIZE_MAX)); } } =20 diff --git a/src/lisp.h b/src/lisp.h index 024e5edb26..02f8a7b668 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -3824,9 +3824,10 @@ extern void mark_maybe_objects (Lisp_Object const = *, ptrdiff_t); extern void mark_stack (char const *, char const *); extern void flush_stack_call_func (void (*func) (void *arg), void *arg); extern void garbage_collect (void); +extern void maybe_garbage_collect (void); extern const char *pending_malloc_warning; extern Lisp_Object zero_vector; -extern intmax_t consing_until_gc; +extern EMACS_INT consing_until_gc; #ifdef HAVE_PDUMPER extern int number_finalizers_run; #endif @@ -5056,7 +5057,7 @@ INLINE void maybe_gc (void) { if (consing_until_gc < 0) - garbage_collect (); + maybe_garbage_collect (); } =20 INLINE_HEADER_END --=20 2.17.1 --------------AE78A0F38C0C63807462A40B-- From unknown Fri Jun 13 10:50:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#37006: 27.0.50; garbage collection not happening after 26de2d42 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Sep 2019 08:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Paul Eggert Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org Received: via spool by 37006-submit@debbugs.gnu.org id=B37006.1568449832371 (code B ref 37006); Sat, 14 Sep 2019 08:31:02 +0000 Received: (at 37006) by debbugs.gnu.org; 14 Sep 2019 08:30:32 +0000 Received: from localhost ([127.0.0.1]:45842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i93Rv-00005k-Uw for submit@debbugs.gnu.org; Sat, 14 Sep 2019 04:30:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i93Rt-00005S-BO for 37006@debbugs.gnu.org; Sat, 14 Sep 2019 04:30:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49108) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i93Rn-0007z4-4z; Sat, 14 Sep 2019 04:30:23 -0400 Received: from [176.228.60.248] (port=2830 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i93Rm-0005cr-HA; Sat, 14 Sep 2019 04:30:22 -0400 Date: Sat, 14 Sep 2019 11:30:39 +0300 Message-Id: <83d0g3z3dc.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Paul Eggert on Sat, 14 Sep 2019 00:51:18 -0700) References: <5075406D-6DB8-4560-BB64-7198526FCF9F@acm.org> <83h86nu0pq.fsf@gnu.org> <86pnlbphus.fsf@phe.ftfl.ca> <83a7cft8qx.fsf@gnu.org> <868srysb9x.fsf@phe.ftfl.ca> <83wofis508.fsf@gnu.org> <2687613f-ba89-25cf-9517-5311106aef9a@cs.ucla.edu> <83ef1prly5.fsf@gnu.org> <0bc956d1-4cf5-a886-1703-49ee0aeb3d58@cs.ucla.edu> <83v9uzrasm.fsf@gnu.org> <18886155-d96b-ae07-1df2-1b1d58a8bbb2@cs.ucla.edu> <83o90qqzqw.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: jrm@ftfl.ca, mattiase@acm.org, 37006@debbugs.gnu.org > From: Paul Eggert > Date: Sat, 14 Sep 2019 00:51:18 -0700 > > On 8/15/19 7:17 AM, Eli Zaretskii wrote: > > OK, but I still hope we will switch to EMACS_INT instead. > > I installed the attached patch into master, and it changes the relevant > threshold variables to EMACS_INT, as part of a somewhat-larger cleanup. Thanks. > This should make a practical difference only on 32-bit Emacs without > --with-wide-int. Right.