From unknown Tue Jun 17 20:21:11 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#77338 <77338@debbugs.gnu.org> To: bug#77338 <77338@debbugs.gnu.org> Subject: Status: feature/igc: when can we run finalizers? Reply-To: bug#77338 <77338@debbugs.gnu.org> Date: Wed, 18 Jun 2025 03:21:11 +0000 retitle 77338 feature/igc: when can we run finalizers? reassign 77338 emacs submitter 77338 Pip Cet severity 77338 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 28 11:04:01 2025 Received: (at submit) by debbugs.gnu.org; 28 Mar 2025 15:04:01 +0000 Received: from localhost ([127.0.0.1]:55092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tyBFY-0007bk-Q1 for submit@debbugs.gnu.org; Fri, 28 Mar 2025 11:04:01 -0400 Received: from lists.gnu.org ([2001:470:142::17]:36776) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tyBFW-0007bV-8Q for submit@debbugs.gnu.org; Fri, 28 Mar 2025 11:03:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tyBFQ-0005xy-EQ for bug-gnu-emacs@gnu.org; Fri, 28 Mar 2025 11:03:52 -0400 Received: from mail-0201.mail-europe.com ([51.77.79.158]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tyBFN-0004BG-0K for bug-gnu-emacs@gnu.org; Fri, 28 Mar 2025 11:03:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1743174223; x=1743433423; bh=uJgmDmSpHrz/pIwzxWt3xKJTyynfJ9BjVuKeTVVwJ0w=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector: List-Unsubscribe:List-Unsubscribe-Post; b=egokP+TQO1cVDT4g6/GTuEmC7irydBse/sfGv1eEXHljcNdH9camrXAx93DYa9+UZ GKYDuVNm6hd+Vs6BzwhphB9Bei6UhW09AU9VdKxsuwtOnl9oqHl24oyz//n7oU7kp7 ePnkw7HitkrHg8OHneW/K+eP1AbMZiql+bG9ClKpLJRtcdqzfx55zpKYhnlPx6+mg3 5G2D/VojjhLK6gZOUvh63enkrE4uByM7jnOkWXOHgKX0hKB09EbSqRCpjCrAu7JUIh Z5Zu5tzyZZbrl1fVaSotvML1xNoFJziTtMsNjGq0UBlIzF+AwRZVwq/qeXYZn3OOBN wdsOfIX005NSg== Date: Fri, 28 Mar 2025 15:03:39 +0000 To: bug-gnu-emacs@gnu.org From: Pip Cet Subject: feature/igc: when can we run finalizers? Message-ID: <87h63djizh.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 5ab168ab7ff553e74b8798fc6773bf865ff7181e MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=51.77.79.158; envelope-from=pipcet@protonmail.com; helo=mail-0201.mail-europe.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) 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: -0.0 (/) In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D77325#14, Daniel writes: > IGC does GC all the time --- but it's not observable because we pump > messages from the GC only at dedicated points and run GC hooks only in > response to these messages. however, notice that on the IGC branch that > we pump GC messages, including finalizer callbacks, on the allocation > path for, e.g. various pseudovectors. That'll cause Lisp to run where > it wouldn't have before. Is that going to be a problem? ISTM we can > either pump messages in maybe_quit() or just rely on igc_on_idle(). That is indeed a bug and one which actually caused a crash for me. It's related to changing the new marker structure to use finalizers rather than attempting to unchain markers in a finalizer rather than doing so in the fix method. The problem is that bignums need to be eagerly finalized or we'll run out of memory running the pidigits benchmark. I'm not sure whether there are other objects which also allocate memory that needs to be freed for correctness. Another problem is that I'm not sure who uses Lisp finalizers and whether the slightly weaker semantics of MPS finalizers suffice for them: IIUC, MPS queues a finalizer when it discovers an object is no longer reachable except through weak references, and doesn't unqueue it even if a weak reference is strengthened again (maphash can do this). So a finalizer can run for an object that actually survived. Is that ever acceptable? Can we prevent it? From debbugs-submit-bounces@debbugs.gnu.org Tue May 20 12:04:25 2025 Received: (at 77338) by debbugs.gnu.org; 20 May 2025 16:04:26 +0000 Received: from localhost ([127.0.0.1]:33475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uHPS4-0003qu-72 for submit@debbugs.gnu.org; Tue, 20 May 2025 12:04:25 -0400 Received: from mail-24417.protonmail.ch ([109.224.244.17]:21581) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uHPRz-0003qB-TI for 77338@debbugs.gnu.org; Tue, 20 May 2025 12:04:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1747757052; x=1748016252; bh=DeKPJjFstRpEYSn7EHE4u+Gu/6ZDBSFVxX+XN4Z3hC8=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=tfXzSUse1kUIlICgsYElUW03wZ6IygXfvRFTXSTwdNe92QJre/37gyBFey/Kv29Xw DN0vYn5JnUSI6FfSD6tLizbXqenoEH8Cbvin0IfFpLd1poIrHUt/4S0oE0RSiJSPDq qXBgjpySZSJ9UO3Gi3Kmpp4x5+4JheYswuOu4501Sl6n5U5z5rbD+ihEUbwgdgvrvc W7m+49k33pWfm8L8V5HpmNdkR2ipfiPSPl3o7E3A5zDl2vPmJdw92FfSW5HtJ9YPQd lRYXQeNYlQaKRcXpMz94O1oRQrwIfc/qJRZYxxG0+UIcpBwb9XZ80qsbriCqZnbtjn kQTnILcwZx3JA== Date: Tue, 20 May 2025 16:04:08 +0000 To: 77338@debbugs.gnu.org From: Pip Cet Subject: Re: bug#77338: feature/igc: when can we run finalizers? Message-ID: <87cyc3clqh.fsf@protonmail.com> In-Reply-To: <87h63djizh.fsf@protonmail.com> References: <87h63djizh.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 6d85cba34e1840abc19b7f99ed0f2d51a9f95073 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77338 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 (-) "Pip Cet via \"Bug reports for GNU Emacs, the Swiss army knife of text edit= ors\"" writes: > In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D77325#14, Daniel > writes: > >> IGC does GC all the time --- but it's not observable because we pump >> messages from the GC only at dedicated points and run GC hooks only in >> response to these messages. however, notice that on the IGC branch that >> we pump GC messages, including finalizer callbacks, on the allocation >> path for, e.g. various pseudovectors. That'll cause Lisp to run where >> it wouldn't have before. Is that going to be a problem? ISTM we can >> either pump messages in maybe_quit() or just rely on igc_on_idle(). > > That is indeed a bug and one which actually caused a crash for me. It's > related to changing the new marker structure to use finalizers rather > than attempting to unchain markers in a finalizer rather than doing so > in the fix method. > > The problem is that bignums need to be eagerly finalized or we'll run > out of memory running the pidigits benchmark. I'm not sure whether > there are other objects which also allocate memory that needs to be > freed for correctness. > > Another problem is that I'm not sure who uses Lisp finalizers and > whether the slightly weaker semantics of MPS finalizers suffice for > them: IIUC, MPS queues a finalizer when it discovers an object is no > longer reachable except through weak references, and doesn't unqueue it > even if a weak reference is strengthened again (maphash can do this). Some investigation revealed that the old GC's behavior for finalizers is even more unusual than that: a finalizer reachable only through weak references will be run (correctly) and left in the weak hash table it was found in (somewhat confusingly, but perhaps unavoidably). However, using a finalizer as a value in a weak-key hash table has the same effect! (setq h (make-hash-table :weakness 'key)) (puthash t (make-finalizer (lambda () (message "finalized"))) h) (garbage-collect) will run the finalizer, even though it never becomes unreachable. > So a finalizer can run for an object that actually survived. Is that > ever acceptable? Can we prevent it? If the current GC's behavior is acceptable, pretty much everything MPS can do must be, too. Pip