From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 28 00:43:02 2025 Received: (at submit) by debbugs.gnu.org; 28 Jun 2025 04:43:03 +0000 Received: from localhost ([127.0.0.1]:45644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVNP3-0000JA-40 for submit@debbugs.gnu.org; Sat, 28 Jun 2025 00:43:02 -0400 Received: from lists.gnu.org ([2001:470:142::17]:39194) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVNP0-0000Id-8f for submit@debbugs.gnu.org; Sat, 28 Jun 2025 00:42: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 1uVNOt-0003dg-U8 for bug-gnu-emacs@gnu.org; Sat, 28 Jun 2025 00:42:52 -0400 Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1uVNOr-0006IG-MK for bug-gnu-emacs@gnu.org; Sat, 28 Jun 2025 00:42:51 -0400 Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-ae04d3d63e6so71388066b.2 for ; Fri, 27 Jun 2025 21:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751085768; x=1751690568; darn=gnu.org; h=mime-version:user-agent:message-id:date:subject:to:from:from:to:cc :subject:date:message-id:reply-to; bh=iZw6GV2vDGi4LFFXG1R6ly2WzWuDpO7jWydYXKft+EY=; b=KpgxRxoPBwNJ4Ny52ewM55pdzoTou2oLgNkiLt/8fx98fNEswzIqZ0pSd9VPYJo1co B98BAzgN5rstNIwDiJnDS49K9Zrgxv0/kMQssFi3ijEJS+y5jAbgbXc1ob+RfR0WJwyE dbYWiwPezHqsTUjoBiJHvEyWjCtxJOf59RQRz1X9km8Zm7czPoaEYChlu1gmnBVOZ1Yv 3wHjK30om0RTrGv4jhT6Y5fZQrLUOcE7APJ+ZkKZHbrhApOcxpVOF6RUGghs0VqBfUXg iLVuVlXlxTZNb6usVnQa48OvmkGEAJqwHWD3zVa3vNn8Z02xbYRs/KiqtYQR/+yAQqSg DR4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751085768; x=1751690568; h=mime-version:user-agent:message-id:date:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=iZw6GV2vDGi4LFFXG1R6ly2WzWuDpO7jWydYXKft+EY=; b=ieH+mb4BZPlspvgejhtg8TF+snW7V83R3Ehf+vaJG7UfBVUR9qNg36d3e8x7pJfpfC FCgS56i8iKYnriqD7ApRmwDSU0y/URZ5lmSw49sPtzNQxsV1hdfBqykaZ8WrbC3oQpZj 1QVMp+uJeP3A7fgmd9v+sQkmQl3vKHraRndAduDvba0khwGhPLMoXk6UBxoCsqvESfad 9bagV6V26Ct1NPWlihZ1yX9Jq66eKZ5PnuTuabsZR6FXsReO+9yZ46lOOKi4A0oKl7Yb zNI7wICPBwO7NzkjPMwsJMCjCd9+yPmdXlKCQnKaDev3iLZYBABDKiTjrP6uUR3WSNCZ GR4g== X-Gm-Message-State: AOJu0YyDBWRjNSAf1A9Uxm5jIVQ7aIBSniqcF3uMXc/mB6/5bvewXnS9 QOp7Qg6rR17fuDm7uIia+n0k6twOTboJuvxNfa3LPEDRfdGUKJvgEI5R7SsouA== X-Gm-Gg: ASbGncu2VRMc01Lg5puDvRoIO3+pqd/qVG5p/kysLxOmoksnjsTRXeiAbFD7afJaonf bN9RGV76Q5Qo5fNGhWEyZqJ82AfSwMcUSxi6An+3we0u8OLFz6zLsyC+1gdo9L37/wlIIA3p3Tv vgqKKsi37FeKnQEx2KhmoDLqz3GR5xeT3Z40BJ2meVQ7xwtDReJAU3DLJtOaYhYHYONVb1UmXSd TCBh6vjQs3IUyfUiKyEVeSWoGF3Cl0ea02oGejQSP49JKZsxvDUAotVKW6PQEaPD3mGqJXELcNa 1LAE6Zl4AZTKVWfaHOHdLH0k+xKJiHfu/3Mw5qRFiBiQmPWiSVlQMU/16PaTQUps7H/iM2sw1ft 9oaYLKuw5y0cIIlanEAbJcSIoT57N2Q== X-Google-Smtp-Source: AGHT+IEBP1i8hva9s2pA4RKOGsyfWs4DubBVOxBzBQeXqMUjZd2xcFPmlgFF2uKKXMpHN3t86lzsAw== X-Received: by 2002:a17:907:1ca7:b0:ae0:c729:8621 with SMTP id a640c23a62f3a-ae3500b3ee6mr533927766b.31.1751085767663; Fri, 27 Jun 2025 21:42:47 -0700 (PDT) Received: from caladan (dial-184179.pool.broadband44.net. [212.46.184.179]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ae3530152b0sm245189466b.0.2025.06.27.21.42.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Jun 2025 21:42:47 -0700 (PDT) From: Helmut Eller To: bug-gnu-emacs@gnu.org Subject: feature/igc [PATCH] Avoid chaining finalizers together X-Debbugs-Cc: Date: Sat, 28 Jun 2025 06:42:45 +0200 Message-ID: <87zfdsjx2y.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=2a00:1450:4864:20::633; envelope-from=eller.helmut@gmail.com; helo=mail-ej1-x633.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-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 (/) --=-=-= Content-Type: text/plain Lisp_Finalizers are currently chained together in a doubly linked list. This prevents them from being collected. I propose that we simply don't use this list with MPS. The first patch is minimalistic: it only skips finalizer_insert when creating finalizers. The second patch is more thorough: it #ifdefs away the prev/next fields entirely. --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Avoid-chaining-finalizers-together.patch >From 7d34a97c704357fa9e34bd87290a60ef1e8e1ff9 Mon Sep 17 00:00:00 2001 From: Helmut Eller Date: Fri, 27 Jun 2025 20:34:27 +0200 Subject: [PATCH 1/2] Avoid chaining finalizers together Lisp_Finalizers used be chained together via the prev/next fields. These links kept all finalizers alive forever. * src/alloc.c (Fmake_finalizer): Don't insert the new finalizer in the finalizers list. It's counterproductive with MPS. * src/igc.c (Figc__process_messages): New subr. Used to test finalizers. (syms_of_igc): Register it. * test/src/igc-tests.el (test-two-finalizers): New test. --- src/alloc.c | 2 ++ src/igc.c | 9 +++++++++ test/src/igc-tests.el | 33 +++++++++++++++++++++++++++++++++ 3 files changed, 44 insertions(+) diff --git a/src/alloc.c b/src/alloc.c index ceda62f5ed6..cf8b8ad4149 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -4173,7 +4173,9 @@ DEFUN ("make-finalizer", Fmake_finalizer, Smake_finalizer, 1, 1, 0, = ALLOCATE_PSEUDOVECTOR (struct Lisp_Finalizer, function, PVEC_FINALIZER); finalizer->function = function; finalizer->prev = finalizer->next = NULL; +#ifndef HAVE_MPS finalizer_insert (&finalizers, finalizer); +#endif return make_lisp_ptr (finalizer, Lisp_Vectorlike); } diff --git a/src/igc.c b/src/igc.c index 61886f5cf90..bfb4caab483 100644 --- a/src/igc.c +++ b/src/igc.c @@ -4171,6 +4171,14 @@ DEFUN ("igc--collect", Figc__collect, Sigc__collect, 0, 0, 0, return Qnil; } +DEFUN ("igc--process-messages", Figc__process_messages, Sigc__process_messages, + 0, 0, 0, doc: /* Allow Emacs to process queued MPS messages. */) + (void) +{ + igc_process_messages (); + return Qnil; +} + size_t igc_hash (Lisp_Object key) { @@ -5456,6 +5464,7 @@ syms_of_igc (void) defsubr (&Sigc_info); defsubr (&Sigc__roots); defsubr (&Sigc__collect); + defsubr (&Sigc__process_messages); defsubr (&Sigc__set_commit_limit); defsubr (&Sigc__add_extra_dependency); defsubr (&Sigc__remove_extra_dependency); diff --git a/test/src/igc-tests.el b/test/src/igc-tests.el index c9e6d895a38..c4bb863b61b 100644 --- a/test/src/igc-tests.el +++ b/test/src/igc-tests.el @@ -37,4 +37,37 @@ set-commit-limit-test (should (equal (assoc-string "commit-limit" (igc-info)) '("commit-limit" 1 -1 0)))) + +(defvar finalizer-1-called nil) +(defvar finalizer-2-called nil) + +(defun finalize-1 () + (message "finalize-1 called") + (setq finalizer-1-called t)) + +(defun finalize-2 () + (message "finalize-2 called") + (setq finalizer-2-called t)) + +(defvar finalizer-1 (cons 1 (make-finalizer #'finalize-1))) +(defvar finalizer-2 (cons 2 (make-finalizer #'finalize-2))) + +;; Finalizers used to be chained together in a doubly linked list. The +;; head of the list was the static variable finalizers (in alloc.c). +;; Those links were strong references and prevented any finalizer from +;; being collected. +(ert-deftest test-two-finalizers () + (let ((garbage-collection-messages t)) + (dotimes (_ 3) + (igc--collect) + (igc--process-messages)) + (should (not finalizer-1-called)) + (should (not finalizer-2-called)) + (setq finalizer-1 nil) + (dotimes (_ 1) + (igc--collect) + (igc--process-messages)) + (should finalizer-1-called) + (should (not finalizer-2-called)))) + ;;; igc-tests.el ends here. -- 2.39.5 --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0002-For-MPS-ifdef-away-the-prev-next-fields-in-Lisp_Fina.patch >From 64ee510fccf61c9f35f1408eddcbf055a7a6f692 Mon Sep 17 00:00:00 2001 From: Helmut Eller Date: Fri, 27 Jun 2025 20:54:18 +0200 Subject: [PATCH 2/2] For MPS, #ifdef away the prev/next fields in Lisp_Finalizer * src/lisp.h (struct Lisp_Finalizer): no more next/prev fields (finalizers, doomed_finalizers, unchain_finalizer): #ifdef away. * src/alloc.c (finalizers, doomed_finalizers, init_finalizer_list) (finalizer_insert, unchain_finalizer Fmake_finalizer) (init_alloc_once_for_pdumper): #ifdef away code related to next/prev/finalizers/doomed_finalizers. * src/pdumper.c (dump_finalizer) (dump_field_finalizer_ref dump_finalizer_list_head_ptr) (Fdump_emacs_portable): #ifdef away code related to next/prev/finalizers/doomed_finalizers. --- src/alloc.c | 13 +++++++------ src/igc.c | 5 +---- src/lisp.h | 5 ++++- src/pdumper.c | 10 +++++++++- 4 files changed, 21 insertions(+), 12 deletions(-) diff --git a/src/alloc.c b/src/alloc.c index cf8b8ad4149..52a6e7d5fee 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -561,6 +561,7 @@ mmap_lisp_allowed_p (void) } #endif +#ifndef HAVE_MPS /* Head of a circularly-linked list of extant finalizers. */ struct Lisp_Finalizer finalizers; @@ -569,6 +570,7 @@ mmap_lisp_allowed_p (void) not a local inside garbage_collect, in case we GC again while running finalizers. */ struct Lisp_Finalizer doomed_finalizers; +#endif /************************************************************************ @@ -4049,6 +4051,7 @@ make_user_ptr (void (*finalizer) (void *), void *p) } #endif +#ifndef HAVE_MPS static void init_finalizer_list (struct Lisp_Finalizer *head) { @@ -4080,6 +4083,7 @@ unchain_finalizer (struct Lisp_Finalizer *finalizer) finalizer->prev = finalizer->next = NULL; } } +#endif #ifndef HAVE_MPS @@ -4172,8 +4176,8 @@ DEFUN ("make-finalizer", Fmake_finalizer, Smake_finalizer, 1, 1, 0, struct Lisp_Finalizer *finalizer = ALLOCATE_PSEUDOVECTOR (struct Lisp_Finalizer, function, PVEC_FINALIZER); finalizer->function = function; - finalizer->prev = finalizer->next = NULL; #ifndef HAVE_MPS + finalizer->prev = finalizer->next = NULL; finalizer_insert (&finalizers, finalizer); #endif return make_lisp_ptr (finalizer, Lisp_Vectorlike); @@ -7696,14 +7700,11 @@ init_alloc_once_for_pdumper (void) mallopt (M_MMAP_MAX, MMAP_MAX_AREAS); /* Max. number of mmap'ed areas. */ #endif +#ifndef HAVE_MPS init_finalizer_list (&finalizers); init_finalizer_list (&doomed_finalizers); -#ifdef HAVE_MPS - igc_root_create_exact_ptr (&finalizers.next); - igc_root_create_exact_ptr (&finalizers.prev); - igc_root_create_exact_ptr (&doomed_finalizers.next); - igc_root_create_exact_ptr (&doomed_finalizers.prev); #endif + refill_memory_reserve (); } diff --git a/src/igc.c b/src/igc.c index bfb4caab483..b20d75baffa 100644 --- a/src/igc.c +++ b/src/igc.c @@ -101,7 +101,7 @@ # ifndef HASH_Lisp_Overlay_AF021DC256 # error "struct Lisp_Overlay changed" # endif -# ifndef HASH_Lisp_Finalizer_7DACDD23C5 +# ifndef HASH_Lisp_Finalizer_E3665AD113 # error "struct Lisp_Finalizer changed" # endif # ifndef HASH_Lisp_Bignum_8732048B98 @@ -2651,8 +2651,6 @@ fix_finalizer (mps_ss_t ss, struct Lisp_Finalizer *f) MPS_SCAN_BEGIN (ss) { IGC_FIX_CALL_FN (ss, struct Lisp_Vector, f, fix_vectorlike); - IGC_FIX12_PVEC (ss, &f->next); - IGC_FIX12_PVEC (ss, &f->prev); } MPS_SCAN_END (ss); return MPS_RES_OK; @@ -3664,7 +3662,6 @@ finalize_finalizer (struct Lisp_Finalizer *f) if (!NILP (fun)) { f->function = Qnil; - unchain_finalizer (f); specpdl_ref count = SPECPDL_INDEX (); ++number_finalizers_run; specbind (Qinhibit_quit, Qt); diff --git a/src/lisp.h b/src/lisp.h index 167f2cb3a8f..3a858233465 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -3191,15 +3191,18 @@ xmint_pointer (Lisp_Object a) FUNCTION contains a reference to the finalizer; i.e., call FUNCTION when it is reachable _only_ through finalizers. */ Lisp_Object function; - +#ifndef HAVE_MPS /* Circular list of all active weak references. */ struct Lisp_Finalizer *prev; struct Lisp_Finalizer *next; +#endif } GCALIGNED_STRUCT; +#ifndef HAVE_MPS extern struct Lisp_Finalizer finalizers; extern struct Lisp_Finalizer doomed_finalizers; void unchain_finalizer (struct Lisp_Finalizer *finalizer); +#endif INLINE bool FINALIZERP (Lisp_Object x) diff --git a/src/pdumper.c b/src/pdumper.c index d73a0704e20..3003aa0b923 100644 --- a/src/pdumper.c +++ b/src/pdumper.c @@ -2304,6 +2304,7 @@ dump_overlay (struct dump_context *ctx, const struct Lisp_Overlay *overlay) return offset; } +#ifndef HAVE_MPS static void dump_field_finalizer_ref (struct dump_context *ctx, void *out, @@ -2317,12 +2318,13 @@ dump_field_finalizer_ref (struct dump_context *ctx, Lisp_Vectorlike, WEIGHT_NORMAL); } +#endif static dump_off dump_finalizer (struct dump_context *ctx, const struct Lisp_Finalizer *finalizer) { -#if CHECK_STRUCTS && !defined (HASH_Lisp_Finalizer_7DACDD23C5) +#if CHECK_STRUCTS && !defined (HASH_Lisp_Finalizer_E3665AD113) # error "Lisp_Finalizer changed. See CHECK_STRUCTS comment in config.h." #endif START_DUMP_PVEC (ctx, &finalizer->header, struct Lisp_Finalizer, out); @@ -2330,8 +2332,10 @@ dump_finalizer (struct dump_context *ctx, only Lisp field, finalizer->function, manually, so we can give it a low weight. */ dump_field_lv (ctx, out, finalizer, &finalizer->function, WEIGHT_NONE); +#ifndef HAVE_MPS dump_field_finalizer_ref (ctx, out, finalizer, &finalizer->prev); dump_field_finalizer_ref (ctx, out, finalizer, &finalizer->next); +#endif return finish_dump_pvec (ctx, &out->header); } @@ -3448,6 +3452,7 @@ dump_charset_table (struct dump_context *ctx) return offset; } +#ifndef HAVE_MPS static void dump_finalizer_list_head_ptr (struct dump_context *ctx, struct Lisp_Finalizer **ptr) @@ -3459,6 +3464,7 @@ dump_finalizer_list_head_ptr (struct dump_context *ctx, dump_object_for_offset (ctx, make_lisp_ptr (value, Lisp_Vectorlike))); } +#endif static void dump_metadata_for_pdumper (struct dump_context *ctx) @@ -4489,10 +4495,12 @@ DEFUN ("dump-emacs-portable", dump_roots (ctx); dump_charset_table (ctx); +#ifndef HAVE_MPS dump_finalizer_list_head_ptr (ctx, &finalizers.prev); dump_finalizer_list_head_ptr (ctx, &finalizers.next); dump_finalizer_list_head_ptr (ctx, &doomed_finalizers.prev); dump_finalizer_list_head_ptr (ctx, &doomed_finalizers.next); +#endif dump_drain_user_remembered_data_hot (ctx); /* We've already remembered all the objects to which GC roots point, -- 2.39.5 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 28 03:24:49 2025 Received: (at 78917) by debbugs.gnu.org; 28 Jun 2025 07:24:50 +0000 Received: from localhost ([127.0.0.1]:46902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVPvd-0006oz-Kr for submit@debbugs.gnu.org; Sat, 28 Jun 2025 03:24:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35596) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVPvb-0006o8-5D for 78917@debbugs.gnu.org; Sat, 28 Jun 2025 03:24:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uVPvV-0008Ia-Ad; Sat, 28 Jun 2025 03:24:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=NRyUJu3X3sr0oVXfBqQZHPpeOxX/U41NP3stBGwJOPs=; b=cDSdkfGnnhvt Vb5K7dz/oyGzrkTuRTJXcsypWUH1qbLANAS33nS8z0He6y6BFLbnWsVDrq1TDJJiAdoYUu5NnkjKd HVF6wKdvNWoEt9D8c/QM/RUMiOAATKNHmERmErXnXiLhf7aPa1C/Nmjy6KK4HsaTZtSbPD80Yr951 qWJPOK3VsMgOG6jg+fwkuQQr4PLzJJW3QmcAP+vOWJUdy7XYYAJIJlL2Sx8q9rY+N/ZyitcPh2Bo7 GahDksJdUr3Flb8jk200IURJq8MEcf4uQlxuO9NPY+Eq6CcmE8ljGk00BYyESG5N/zNqIWj/bSXV/ 8/OtCjedJFJOIl0R2E3u0A==; Date: Sat, 28 Jun 2025 10:24:38 +0300 Message-Id: <86tt408h1l.fsf@gnu.org> From: Eli Zaretskii To: Helmut Eller , Daniel Colascione In-Reply-To: <87zfdsjx2y.fsf@gmail.com> (message from Helmut Eller on Sat, 28 Jun 2025 06:42:45 +0200) Subject: Re: bug#78917: feature/igc [PATCH] Avoid chaining finalizers together References: <87zfdsjx2y.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78917 Cc: 78917@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 (---) > From: Helmut Eller > Date: Sat, 28 Jun 2025 06:42:45 +0200 > > Lisp_Finalizers are currently chained together in a doubly linked list. > This prevents them from being collected. I propose that we simply don't > use this list with MPS. > > The first patch is minimalistic: it only skips finalizer_insert when > creating finalizers. > > The second patch is more thorough: it #ifdefs away the prev/next fields > entirely. Thanks. Daniel, could you please tell what was the intended purpose of chaining the finalizers? From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 28 04:31:04 2025 Received: (at 78917) by debbugs.gnu.org; 28 Jun 2025 08:31:04 +0000 Received: from localhost ([127.0.0.1]:47659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVQxj-0007QE-Pf for submit@debbugs.gnu.org; Sat, 28 Jun 2025 04:31:04 -0400 Received: from mail-10630.protonmail.ch ([79.135.106.30]:36123) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVQxg-0007Os-OC for 78917@debbugs.gnu.org; Sat, 28 Jun 2025 04:31:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1751099453; x=1751358653; bh=2CcALJXNFmUa0pZ+FKIDDb/lLjq44bz8hk5JoKcs6Y0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=BlcnjjSPFxez5YkYoGtHvGm+cQHLNB9n4Qy9o7we48D+kLC6v3OC0bD5GgWSradf7 UOZw/1XMq8TV2183OOcSf+tON7WDQCWm1A1RD7Qh1GnqEY1gAawaC37nCBFrsfCuKk jxwc4ZKCVEkEwH4xiGhhEEG/KTurWLQ9WzMbKTkTZn5uDalN54EhGjc0fTehpuzmoV 0FcNivY3sG4s3OZPrcmwx367MPdbl+NSRZTfuYY4S5I2cQHWVL+YrTgR8XTqi4Zpaj eXe/x3WyA+GgNv+c6CWWLbmrAy3v8D2GQ9IIkc7DWrSmZITxh5m5lbWpdvnnt8seOt nUPtddH6xCV9A== Date: Sat, 28 Jun 2025 08:30:49 +0000 To: Helmut Eller From: Pip Cet Subject: Re: bug#78917: feature/igc [PATCH] Avoid chaining finalizers together Message-ID: <87ikkg2rpp.fsf@protonmail.com> In-Reply-To: <87zfdsjx2y.fsf@gmail.com> References: <87zfdsjx2y.fsf@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: f53f7c4a6fd85a9c1d5af7c4d4d7e984853c498d 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: 78917 Cc: 78917@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: -1.0 (-) "Helmut Eller" writes: > Lisp_Finalizers are currently chained together in a doubly linked list. > This prevents them from being collected. I propose that we simply don't > use this list with MPS. See https://lists.gnu.org/archive/html/emacs-devel/2025-05/msg00468.html and bug#77338. The way finalizers are currently run on the master branch when they appear in weak tables, even if there is no chance that the entry that references them is ever collected, makes them pretty much unusable on that branch, in my book. Making them usable with --with-mps=3Dyes isn't much of a priority for me, TBH, as code using them would break when we compile without MPS support. (I considered using finalizers for font finalization; it works, but would break if a strong reference to the font is mistaken for a weak one and fails to keep alive the font). Pip From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 28 05:14:27 2025 Received: (at 78917) by debbugs.gnu.org; 28 Jun 2025 09:14:27 +0000 Received: from localhost ([127.0.0.1]:47824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVRdi-00052h-Qn for submit@debbugs.gnu.org; Sat, 28 Jun 2025 05:14:27 -0400 Received: from mail-24417.protonmail.ch ([109.224.244.17]:44011) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVRde-00050w-Sp for 78917@debbugs.gnu.org; Sat, 28 Jun 2025 05:14:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1751102056; x=1751361256; bh=r02nut/Vo+pxG9T0hH/BIfHK4kt8ipkstuMN/UPuuSo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=EmuzZK6zSNGx1hoymALt76yongUZnydTegdReNZEJeX6+YlNK8nPjR5EpodFO/Htj WgLf138ASdDqH3AeLfo2d/fINmVRdq34J1hXHFCUc2c9Z/ELAS+pDAQiSvRQPHe9NP Xihy4Wek5PNoOciSchc4XV6wzn/8WEK+J55kw2wC804xq6rxAgIVyEGju0Y7B/csTf PTx9yOwb1Vdd4GCJdAKsFRxX0Me0WJxBJ0jddPPvanzHvdIV/m06zs778uN/46Wi8g inqxJeruXt+yZZou6fnSTIpGaaZFsvSFg8CX64z2ikfHNvOVSGxRQqWqFp1lzvTIyp ZYIAW8zs99+nQ== Date: Sat, 28 Jun 2025 09:14:12 +0000 To: Helmut Eller From: Pip Cet Subject: Re: bug#78917: feature/igc [PATCH] Avoid chaining finalizers together Message-ID: <87a55s2ppa.fsf@protonmail.com> In-Reply-To: <87zfdsjx2y.fsf@gmail.com> References: <87zfdsjx2y.fsf@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 76baba0897a35c9da3a587c6c0c741d0521dd55e 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: 78917 Cc: 78917@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: -1.0 (-) "Helmut Eller" writes: > Lisp_Finalizers are currently chained together in a doubly linked list. > This prevents them from being collected. I propose that we simply don't > use this list with MPS. > > The first patch is minimalistic: it only skips finalizer_insert when > creating finalizers. > > The second patch is more thorough: it #ifdefs away the prev/next fields > entirely. Looks good, except for the addition of igc--process-messages; igc--collect should process *all* messages before returning, and exposing a function that processes only some of the messages doesn't seem useful to me. The test probably should be rewritten to something like this: ;; Ensure finalizers are collected and bug#78917 doesn't reappear. (ert-deftest test-two-finalizers () ;; this test will usually succeed, but might fail due to unpredictable ;; references to the finalizer on the C stack or elsewhere. :tags '(:igc :unstable) (let* ((garbage-collection-messages t) (finalizer-1-called nil) (finalizer-2-called nil) (finalizer-1 (make-finalizer (lambda (setq finalizer-1-called t)))= ) (finalizer-2 (make-finalizer (lambda (setq finalizer-2-called t)))= )) (dotimes (_ 3) (igc--collect) (sleep-for 0.1)) (should (not finalizer-1-called)) (should (not finalizer-2-called)) (setq finalizer-1 nil) (dotimes (_ 1) (igc--collect) (accept-process-output nil 1 0 t)) (should finalizer-1-called) (should (not finalizer-2-called)))) Pip From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 28 16:22:10 2025 Received: (at 78917) by debbugs.gnu.org; 28 Jun 2025 20:22:10 +0000 Received: from localhost ([127.0.0.1]:52201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVc3u-0006Va-1v for submit@debbugs.gnu.org; Sat, 28 Jun 2025 16:22:10 -0400 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]:57747) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uVc3r-0006U8-Hb for 78917@debbugs.gnu.org; Sat, 28 Jun 2025 16:22:08 -0400 Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-6077dea37easo1486333a12.3 for <78917@debbugs.gnu.org>; Sat, 28 Jun 2025 13:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751142121; x=1751746921; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=UPmehEahTEpq/i5v962uavd3/3SKjh/UTjjFkE4E6zk=; b=m4iOe5bHFK8Q4cycSySF4cKCGd6yx3FWJPZzXQ3jDh+jchfZ8MQOXiVpDN3vU5bM9g i9Ptg1jR1CDiiHUAUmy53vKiwSi0Ll0WyfBZ2U/27lzH6EX0r01SQaH4JoNx426A1uxl OF5m3ZMFPDAcwVHxrwN5aUVDlWVfxkgOtOnxiDmtvmFRz8chjDFV04gCT5Tk/v3DKyFV hGvFHOLlfjrLtBbKLumWYsuUiHP79pf16YyGd/1cpOwCgfS6Q8wxEV0OmUY478dnqzvj EeKiUGo++6OjKB1+7l97cAfCK0F2aXizXU6PN1mJeV+AS6iJak1j4bB6dnDWdkvtscYt WwXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751142121; x=1751746921; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UPmehEahTEpq/i5v962uavd3/3SKjh/UTjjFkE4E6zk=; b=V+svKLK8tDz/6K3GjcuxDkLMG2ru46PFfBORpnvRJOaSNrEzL1Eg7xPo6+7LBINL/q e/nFzKaFyZ0wmAfIf/ocEywyVDevg9bjr7FoXeZ2DihW+taGmeF+LzgMrFpASO421nDT 2dpZHBwS047KyYsoNDPIxvOFaRYUbzEKm7qmCh9Q0YqyDBuyMDjm+G5Sq//eZyxJdEfZ zV1oWvdfQ+MVzbnNRwmUqU8OwAarkDZd0GcFOknDWiZVbDo3rCexEfctd7/ZgQvH32Wh cJ1sJy1HD37rSEpy5fk+dl62HhyIqpS4rg7ZIybdNAwThIwjlqPscKt/cxdQjRJh4Quz J07g== X-Gm-Message-State: AOJu0Yx6ha6UxYiO2/nb+WdZtVop/IjqEiZ2FSs6zyeEsgD2Hnmg/Mu8 kjoFQR3uM1MutbQs5ElkZq5nvJw6skILKf46eIS5nEG2Z7HeCNWQK5RKULN/Rw== X-Gm-Gg: ASbGncsqkMcUpj10ho97CqlXmk5a8BEZmQ407YoU6S0BaUU1is3jQtmPH2tVlVIO6Zj IQa422cwthmW2OEPXJZFooqWbqsn09EyK9eTWe0PAaOVU4gDx3xG5Hxksts3asDn7KvzoywzMHi ks9mYEA8qFetuum7h5sfk2V9jODGHZWrAAX0GTDwCU3YNuP4nhemfJxugOlqKev2kTyKSWV3/Mo cWMnwl3ne8BWqDig74S8HYbwzcsvj3ZTCwAywGkAp6F1Z0/3pieCoI44C80mME5saAJGJLAH3xY D25CoTDgu1p4IMbjn1ACYaWM8wniwYgjGtKYoNLQFd/dbYFnpTd7ue92ILAx1e7p2PLpQg2ReWI +J9QBF8F9QET6ZDSReIM= X-Google-Smtp-Source: AGHT+IEb/qIj+eDewqDOHTfhdRXr/xFpkzWNwoeYlY9vTZuglktxkuDQC0z8WnzPPxEDS3owtq13jg== X-Received: by 2002:a17:906:9fcd:b0:adb:449c:7621 with SMTP id a640c23a62f3a-ae3500b8ed9mr856736166b.29.1751142120651; Sat, 28 Jun 2025 13:22:00 -0700 (PDT) Received: from caladan (dial-184179.pool.broadband44.net. [212.46.184.179]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ae353c6b418sm361790566b.110.2025.06.28.13.21.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Jun 2025 13:22:00 -0700 (PDT) From: Helmut Eller To: Pip Cet Subject: Re: bug#78917: feature/igc [PATCH] Avoid chaining finalizers together In-Reply-To: <87ikkg2rpp.fsf@protonmail.com> References: <87zfdsjx2y.fsf@gmail.com> <87ikkg2rpp.fsf@protonmail.com> Date: Sat, 28 Jun 2025 22:21:59 +0200 Message-ID: <87ecv3k460.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78917 Cc: 78917@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: -1.0 (-) --=-=-= Content-Type: text/plain On Sat, Jun 28 2025, Pip Cet wrote: > "Helmut Eller" writes: > >> Lisp_Finalizers are currently chained together in a doubly linked list. >> This prevents them from being collected. I propose that we simply don't >> use this list with MPS. > > See https://lists.gnu.org/archive/html/emacs-devel/2025-05/msg00468.html :-) > and bug#77338. It seems that the problem with finalizers as value in a weak hashtable could be fixed by calling mark_and_sweep_weak_table_contents before queue_doomed_finalizers as in the patch below. > The way finalizers are currently run on the master branch when they > appear in weak tables, even if there is no chance that the entry that > references them is ever collected, makes them pretty much unusable on > that branch, in my book. Making them usable with --with-mps=yes isn't > much of a priority for me, TBH, as code using them would break when we > compile without MPS support. Putting finalizers in a weak hashtable sounds exotic. I suppose there should be tests for this. > (I considered using finalizers for font finalization; it works, but > would break if a strong reference to the font is mistaken for a weak one > and fails to keep alive the font). There is some "hardcoded" finalization code in cleanup_vector for PVEC_FONT. Maybe you could use that instead of Lisp_Finalizers. Helmut --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=alloc.diff diff --git a/src/alloc.c b/src/alloc.c index 07ca8474bf3..f784bd91da7 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -5965,6 +5965,10 @@ garbage_collect (void) mark_object (BVAR (nextb, undo_list)); } + /* Must happen after all other marking and before gc_sweep. */ + mark_and_sweep_weak_table_contents (); + eassert (weak_hash_tables == NULL); + /* Now pre-sweep finalizers. Here, we add any unmarked finalizers to doomed_finalizers so we can run their associated functions after GC. It's important to scan finalizers at this stage so @@ -5975,10 +5979,6 @@ garbage_collect (void) queue_doomed_finalizers (&doomed_finalizers, &finalizers); mark_finalizer_list (&doomed_finalizers); - /* Must happen after all other marking and before gc_sweep. */ - mark_and_sweep_weak_table_contents (); - eassert (weak_hash_tables == NULL); - eassert (mark_stack_empty_p ()); gc_sweep (); --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 28 16:42:29 2025 Received: (at 78917) by debbugs.gnu.org; 28 Jun 2025 20:42:30 +0000 Received: from localhost ([127.0.0.1]:52242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVcNX-00017v-M3 for submit@debbugs.gnu.org; Sat, 28 Jun 2025 16:42:29 -0400 Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]:55743) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uVcNS-00016D-OD for 78917@debbugs.gnu.org; Sat, 28 Jun 2025 16:42:25 -0400 Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-ae223591067so155003066b.3 for <78917@debbugs.gnu.org>; Sat, 28 Jun 2025 13:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751143336; x=1751748136; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=QvAdFBZWYUIUPgvvC8x6jx2vp5Rme8kquR6BUOD6gYg=; b=Li0NxBQfIX8g0YMTnMIwIKfjTBzrSnMkV9ZAYvMk1OFX7rLQUOCvfiSSBYkCgc3YNj uZQKGyO7kCy4O4V46bY2eF7lhrfIxllmVRUERv4oFd5efffjW6Wq8he52noyvRpd65gX NzinAyUB+BWIQGm3CiMXJjqnNngyBtT8gWy7HnzMCVbOnYWJiwRpkU/Tn6mLI7jyL85D WPqR0pQPwafI/SafFq29JRFQ7iZwgK/ADnIis89GQ/TEjKqig1sj11/6phMlJIAZy6f0 hLAmpSccGfA5ZNixpb5X1yAOR3WOfXaMO2wk4BZebtODv+PoZ9VYQ4ortcb27pX8oaEJ 6rDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751143336; x=1751748136; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QvAdFBZWYUIUPgvvC8x6jx2vp5Rme8kquR6BUOD6gYg=; b=ZQQJjRdh2vCOZx28ZhksF5BpZks4pG0k1g+ietOvc7c9116JWv9+dZTh+UaA8cV6/2 zlXSIgn1i17TqK8Wnn9iEIpweT3jVoGKfC8rLnc1mV1wqfx8LB4rVr50qlT7PFFFVb9E ubryAtmUcXCXJrh3ETUuOr9h3HooNEAi1WNP/d/QpW+udUJzUZ6aSI7T390tW0PCGEYS d0Jv5lznFAcQfFrk83/qZZrSTSazespwM28ICjEFQjmBiHSyp4zXserOryG9GZVHJ2+p jMxC1swC978nyCsnBPGFiJyIPcati59oa3Qn+lcXHMZ76pewbppXJt435I6NvT7y5uI1 X72g== X-Gm-Message-State: AOJu0YxVXJ8sYMLNMgNsv97TxE6hhM1RxUNvjWCdjJHvO/8nwS4pdUkt SKU4BQs/aXpXqaXSRxcJev6AyMLdJYW6j/lt3zviBUygD06BOzcGMfxA9odfYA== X-Gm-Gg: ASbGnctAZ+6ZYbkux3jAaaBxBl5+cO0jMixpgfdLMe7s/uHZs/r113lA+Q/6ZNVqpQ/ 05TQwW5fuWAYC4m8t+82N/K8gCuath8PWK3125pBvhvrEuX/DBooUDZtFHFsqEzUzBVXRsh7RiE ppebbE5Nzt2nEQxcoputlw+sGLnaZwY1tkdx7yz5wphG4FchYLtZQIBy7gndSP8j8mWSEpSj3vx C487sx+lICbm/52ApVBavJf7PN7Tlt7T/1ZsvZ7owVk5ijEPcd/ZvKwUPdttsjsZ7kVBbIXjAeJ ze7kx3vFddLVkJLMECzlC94ILYzpap3BSOEJZPiCc4ktGoaN7VhTCJ7AqS8VLRikDuVNftdJ5Dp s6VSVpf3cVmk3W29yeQ2wK0anYrRnjw== X-Google-Smtp-Source: AGHT+IEvshIdaFK+iQHvFVdFK6nhDOCLPfu0XFRVLAHkg7dRU/36vmn381MQBP8CR8lWlLYLWc3VZg== X-Received: by 2002:a17:907:96ab:b0:adb:2ef9:db38 with SMTP id a640c23a62f3a-ae3500f2822mr883490066b.36.1751143336258; Sat, 28 Jun 2025 13:42:16 -0700 (PDT) Received: from caladan (dial-184179.pool.broadband44.net. [212.46.184.179]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ae353c6bfafsm371050466b.130.2025.06.28.13.42.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Jun 2025 13:42:15 -0700 (PDT) From: Helmut Eller To: Pip Cet Subject: Re: bug#78917: feature/igc [PATCH] Avoid chaining finalizers together In-Reply-To: <87a55s2ppa.fsf@protonmail.com> References: <87zfdsjx2y.fsf@gmail.com> <87a55s2ppa.fsf@protonmail.com> Date: Sat, 28 Jun 2025 22:42:15 +0200 Message-ID: <871pr3k388.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78917 Cc: 78917@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: -1.0 (-) On Sat, Jun 28 2025, Pip Cet wrote: > "Helmut Eller" writes: > >> Lisp_Finalizers are currently chained together in a doubly linked list. >> This prevents them from being collected. I propose that we simply don't >> use this list with MPS. >> >> The first patch is minimalistic: it only skips finalizer_insert when >> creating finalizers. >> >> The second patch is more thorough: it #ifdefs away the prev/next fields >> entirely. > > Looks good, except for the addition of igc--process-messages; > igc--collect should process *all* messages before returning, Maybe. igc-collect (the one from igc.el) could easily call igc--process-messages, though. > exposing a function that processes only some of the messages doesn't > seem useful to me. It's useful to test finalizes. It would be more useful to have an API to test finalizers that works for both MPS and non-MPS configurations. A candidate is (progn (garbage-collect) (accept-process-output)) but I guess that a plain (garbage-collect) is what most people would prefer. > The test probably should be rewritten to something like this: > > ;; Ensure finalizers are collected and bug#78917 doesn't reappear. > (ert-deftest test-two-finalizers () > ;; this test will usually succeed, but might fail due to unpredictable > ;; references to the finalizer on the C stack or elsewhere. > :tags '(:igc :unstable) > (let* ((garbage-collection-messages t) > (finalizer-1-called nil) > (finalizer-2-called nil) > (finalizer-1 (make-finalizer (lambda (setq finalizer-1-called t)))) > (finalizer-2 (make-finalizer (lambda (setq finalizer-2-called t))))) > (dotimes (_ 3) > (igc--collect) > (sleep-for 0.1)) > (should (not finalizer-1-called)) > (should (not finalizer-2-called)) > (setq finalizer-1 nil) > (dotimes (_ 1) > (igc--collect) > (accept-process-output nil 1 0 t)) > (should finalizer-1-called) > (should (not finalizer-2-called)))) Have you tried it? This doesn't work for me. Helmut From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 28 16:53:17 2025 Received: (at 78917) by debbugs.gnu.org; 28 Jun 2025 20:53:18 +0000 Received: from localhost ([127.0.0.1]:52276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVcXz-0002rh-1J for submit@debbugs.gnu.org; Sat, 28 Jun 2025 16:53:17 -0400 Received: from mail-4316.protonmail.ch ([185.70.43.16]:28983) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVcXv-0002qT-LF for 78917@debbugs.gnu.org; Sat, 28 Jun 2025 16:53:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1751143984; x=1751403184; bh=UfpaUkzixYXUblMYDqRg4rpf3cb/AWATBBLdt+4koHE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=P1gTMPm1wJwoYFEQ2DcDrHobqg/C+GmLSkWuY345Km097G9ciiw9+LUws6iCtZp+b lLtNQtgbhT8mInt7TL9408IKUm8vxmbZxBKs5sgNaAygXQz729iFkgOrUgOnBTusB0 MtOYRiJtvBRzhinoiKTLkh3kqhyN4Wio5gjvwWDi3WJpcnXEn8T6ScILLV/YoRt8Qi uiuPOpKdHpMbMHdJmCdXUdQmqxLslznGMbQJ6W3Ifu3N2RNmePwUy53KUqECCnsMYv 7Gk/p/Nx2muvg1OqRZFBMuK486U7coBrXusjygsEI9OOqF2KNuB6O2M9UyuDGNDWHO O39gmW3BC0ZVQ== Date: Sat, 28 Jun 2025 20:52:58 +0000 To: Helmut Eller From: Pip Cet Subject: Re: bug#78917: feature/igc [PATCH] Avoid chaining finalizers together Message-ID: <87h5zz1tcq.fsf@protonmail.com> In-Reply-To: <871pr3k388.fsf@gmail.com> References: <87zfdsjx2y.fsf@gmail.com> <87a55s2ppa.fsf@protonmail.com> <871pr3k388.fsf@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 0262eabc7e4a1f9f647a247e67462125bdd55382 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: 78917 Cc: 78917@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: -1.0 (-) "Helmut Eller" writes: > On Sat, Jun 28 2025, Pip Cet wrote: > >> "Helmut Eller" writes: >> >>> Lisp_Finalizers are currently chained together in a doubly linked list. >>> This prevents them from being collected. I propose that we simply don'= t >>> use this list with MPS. >>> >>> The first patch is minimalistic: it only skips finalizer_insert when >>> creating finalizers. >>> >>> The second patch is more thorough: it #ifdefs away the prev/next fields >>> entirely. >> >> Looks good, except for the addition of igc--process-messages; >> igc--collect should process *all* messages before returning, > > Maybe. igc-collect (the one from igc.el) could easily call > igc--process-messages, though. That would work as well, if igc--process-messages processed all messages (or returned to the caller some indication that it failed to do so). >> exposing a function that processes only some of the messages doesn't >> seem useful to me. > > It's useful to test finalizes. It would be more useful to have an API > to test finalizers that works for both MPS and non-MPS configurations. As you can't reliably test finalizers, it's not a huge problem if trying to do so anyway requires some more code. > but I guess that a plain > > (garbage-collect) > > is what most people would prefer. Hmm. I think (garbage-collect) should become a nop in MPS builds. >> The test probably should be rewritten to something like this: >> >> ;; Ensure finalizers are collected and bug#78917 doesn't reappear. >> (ert-deftest test-two-finalizers () >> ;; this test will usually succeed, but might fail due to unpredictable >> ;; references to the finalizer on the C stack or elsewhere. >> :tags '(:igc :unstable) >> (let* ((garbage-collection-messages t) >> (finalizer-1-called nil) >> (finalizer-2-called nil) >> (finalizer-1 (make-finalizer (lambda (setq finalizer-1-called t= )))) >> (finalizer-2 (make-finalizer (lambda (setq finalizer-2-called t= ))))) >> (dotimes (_ 3) >> (igc--collect) >> (sleep-for 0.1)) >> (should (not finalizer-1-called)) >> (should (not finalizer-2-called)) >> (setq finalizer-1 nil) >> (dotimes (_ 1) >> (igc--collect) >> (accept-process-output nil 1 0 t)) >> (should finalizer-1-called) >> (should (not finalizer-2-called)))) > > Have you tried it? This doesn't work for me. I modified igc--collect as described above. Pip From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 28 17:37:28 2025 Received: (at 78917) by debbugs.gnu.org; 28 Jun 2025 21:37:28 +0000 Received: from localhost ([127.0.0.1]:52444 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVdEl-0001vi-Rj for submit@debbugs.gnu.org; Sat, 28 Jun 2025 17:37:28 -0400 Received: from mail-4316.protonmail.ch ([185.70.43.16]:23425) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVdEi-0001uO-Bz for 78917@debbugs.gnu.org; Sat, 28 Jun 2025 17:37:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1751146637; x=1751405837; bh=Ee8CINP8d/L9vfDyaFcugFiTFVJrf4aq4vars5CUtmU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=QskoEbNlrQNlrSRx0fUKCPEEby0rppGjzCzRPbL+MY5gX+JUC4jtoj+VYe30dDYAm avxstuuTqUvbdSPWQzcrlVojZfkX+u+MyZ6YFVDKyFQPW44mgasGuGzRWJciGuyD+P grY2fLF6WidknlrZR2mHWo49Ox0/uUTvbOqzk612VAqX5hIRLR6KxEFyGxYXk7lvCR vRzSCQ5sQw0pDUzh29eP4tEpB+m06vW7XBdPnkiF2Gi8Bf69MwRVrzpHvFuFAvM0g1 qbkYxUK3ZK1fXSvgKHQ4qnE2daRhkaWOgrMuZpjt+7LYAqgAFVE72QBhDBfjGdvE2I eBg29mUpw2vKA== Date: Sat, 28 Jun 2025 21:37:11 +0000 To: Helmut Eller From: Pip Cet Subject: Re: bug#78917: feature/igc [PATCH] Avoid chaining finalizers together Message-ID: <878qlb1rb0.fsf@protonmail.com> In-Reply-To: <87ecv3k460.fsf@gmail.com> References: <87zfdsjx2y.fsf@gmail.com> <87ikkg2rpp.fsf@protonmail.com> <87ecv3k460.fsf@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: cac3904050273a0fb971584dd58be924300cf93e 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: 78917 Cc: 78917@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: -1.0 (-) "Helmut Eller" writes: > On Sat, Jun 28 2025, Pip Cet wrote: > >> "Helmut Eller" writes: >> >>> Lisp_Finalizers are currently chained together in a doubly linked list. >>> This prevents them from being collected. I propose that we simply don'= t >>> use this list with MPS. >> >> See https://lists.gnu.org/archive/html/emacs-devel/2025-05/msg00468.html > > :-) > >> and bug#77338. > > It seems that the problem with finalizers as value in a weak hashtable > could be fixed by calling mark_and_sweep_weak_table_contents before > queue_doomed_finalizers as in the patch below. No, that's not the right fix: a finalizer function can still refer to weak hash tables (the finalizer itself is not a weak object), so we can't sweep the weak hash tables until all finalizers have been marked. This is solvable, but it requires more effort than exchanging those two calls. However, I'm not sure we should fix the traditional GC code to be better than what MPS can do :-) >> The way finalizers are currently run on the master branch when they >> appear in weak tables, even if there is no chance that the entry that >> references them is ever collected, makes them pretty much unusable on >> that branch, in my book. Making them usable with --with-mps=3Dyes isn't >> much of a priority for me, TBH, as code using them would break when we >> compile without MPS support. > > Putting finalizers in a weak hashtable sounds exotic. I suppose there > should be tests for this. Putting font objects in a weak hash table doesn't seem exotic to me. >> (I considered using finalizers for font finalization; it works, but >> would break if a strong reference to the font is mistaken for a weak one >> and fails to keep alive the font). > > There is some "hardcoded" finalization code in cleanup_vector for > PVEC_FONT. Maybe you could use that instead of Lisp_Finalizers. The point was to get rid of that (unstable and problematic) code :-) Pip From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 29 14:20:47 2025 Received: (at 78917) by debbugs.gnu.org; 29 Jun 2025 18:20:48 +0000 Received: from localhost ([127.0.0.1]:58855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVwdx-0005kt-Nk for submit@debbugs.gnu.org; Sun, 29 Jun 2025 14:20:47 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:45762) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVwds-0005jo-UV for 78917@debbugs.gnu.org; Sun, 29 Jun 2025 14:20:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=D6NpcBb9kaLWHvRZRK8rlzulwbZTOBf7/fsGeX4tALU=; b=CNf/7BzcgpctzMIkdyJUT/Lo5p SdmY9yWxadcA8NLJKxyiiHdLXnWqQzbC5009Y6rYlRN2dqp/Dq9lFf+k08e5xUo079b9Hs8yUnxd7 gNVXg1Se0NJtsO52MWcaIp/n5hanJQqs+x55AvJXMofWqQWhtTAvB659WU08c0Xbx0RTRoQ2GBgzs B3dUlWzlW4ofvIRFtqLusBvd50OJLpiqrcvtc8YVxYsXCqzlmwiTpwbXiz/2evFqI1k0Bl4z7mnRV 3T9u9bksWD7kJo7zFTuq/8f3Fxlw+wGuTYZXqCYvYXYcCauWvj91bZHQd8N8qVDlZTpZ7GsciyQMC EWdAa/7g==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uVwcL-00DGeU-1E; Sun, 29 Jun 2025 14:19:05 -0400 From: Daniel Colascione To: Eli Zaretskii Subject: Re: bug#78917: feature/igc [PATCH] Avoid chaining finalizers together In-Reply-To: <86tt408h1l.fsf@gnu.org> References: <87zfdsjx2y.fsf@gmail.com> <86tt408h1l.fsf@gnu.org> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Sun, 29 Jun 2025 14:20:38 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 78917 Cc: 78917@debbugs.gnu.org, Helmut Eller 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 (-) Eli Zaretskii writes: >> From: Helmut Eller >> Date: Sat, 28 Jun 2025 06:42:45 +0200 >> >> Lisp_Finalizers are currently chained together in a doubly linked list. >> This prevents them from being collected. I propose that we simply don't >> use this list with MPS. >> >> The first patch is minimalistic: it only skips finalizer_insert when >> creating finalizers. >> >> The second patch is more thorough: it #ifdefs away the prev/next fields >> entirely. > > Thanks. > > Daniel, could you please tell what was the intended purpose of > chaining the finalizers? How else do you sweep the unreachable ones at the end of GC? From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 29 14:28:31 2025 Received: (at submit) by debbugs.gnu.org; 29 Jun 2025 18:28:32 +0000 Received: from localhost ([127.0.0.1]:58873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVwlT-0006tf-BP for submit@debbugs.gnu.org; Sun, 29 Jun 2025 14:28:31 -0400 Received: from lists.gnu.org ([2001:470:142::17]:37464) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVwlM-0006rM-3L for submit@debbugs.gnu.org; Sun, 29 Jun 2025 14:28:25 -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 1uVwlB-0001pj-4W for bug-gnu-emacs@gnu.org; Sun, 29 Jun 2025 14:28:13 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uVwl5-00074F-TI for bug-gnu-emacs@gnu.org; Sun, 29 Jun 2025 14:28:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=cs/aUKpSUDpY0Xh2GR7N6DHTtBQlk+b6PMNL6+EIa78=; b=euvs3UcNbjS+FZmWTjgm225EaP tb/irjISK6qN4zZohwHC3eV5fcQ2YzB4Lrbl2OYLrsPMccvo8DbBbX2Bu4VOlLXHdzay76c9jWQEa MzZkG4ioR28v5xwh9oW5PPZeU6+3keNWQrmYhaO8TaYWA5g94P/NRKJddITc4atOq73neFPJtnoNB 8yl1SIHoFeXwnQ1YVJaHnA67hWG8ClVo1BHhZBuKZvdzi6cG012mrImB6+dC9BeT2+2usmzmG9rSd y6s4NF3mxQGOqFPKqU0rJDM0lZPP4G68x84R+UpC5vSTcVTymkLGYTiD/BZF29DBeJPAZqRQo3VnS gXxdKzuA==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uVwjV-00DH1h-31; Sun, 29 Jun 2025 14:26:29 -0400 From: Daniel Colascione To: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#78917: feature/igc [PATCH] Avoid chaining finalizers together In-Reply-To: <878qlb1rb0.fsf@protonmail.com> References: <87zfdsjx2y.fsf@gmail.com> <87ikkg2rpp.fsf@protonmail.com> <87ecv3k460.fsf@gmail.com> <878qlb1rb0.fsf@protonmail.com> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Sun, 29 Jun 2025 14:28:02 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@dancol.org; helo=dancol.org 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit Cc: 78917@debbugs.gnu.org, Pip Cet , Helmut Eller 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.1 (/) Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > "Helmut Eller" writes: > >> On Sat, Jun 28 2025, Pip Cet wrote: >> >>> "Helmut Eller" writes: >>> >>>> Lisp_Finalizers are currently chained together in a doubly linked list. >>>> This prevents them from being collected. I propose that we simply don't >>>> use this list with MPS. >>> >>> See https://lists.gnu.org/archive/html/emacs-devel/2025-05/msg00468.html >> >> :-) >> >>> and bug#77338. >> >> It seems that the problem with finalizers as value in a weak hashtable >> could be fixed by calling mark_and_sweep_weak_table_contents before >> queue_doomed_finalizers as in the patch below. Ouch. That branch of the discussion of bug#77338 slipped past me. Thanks for bringing it up. Gut feeling is that the solution is some kind of iterated walk over finalizers and weak tables until we reach a fixed point? Let me think it over. > > No, that's not the right fix: a finalizer function can still refer to > weak hash tables (the finalizer itself is not a weak object), so we > can't sweep the weak hash tables until all finalizers have been marked. > > This is solvable, but it requires more effort than exchanging those two > calls. > > However, I'm not sure we should fix the traditional GC code to be better > than what MPS can do :-) Emacs 31 is going to live a long time and igc won't be its default GC. From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 29 15:02:58 2025 Received: (at submit) by debbugs.gnu.org; 29 Jun 2025 19:02:59 +0000 Received: from localhost ([127.0.0.1]:58943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVxIn-0004M1-9j for submit@debbugs.gnu.org; Sun, 29 Jun 2025 15:02:58 -0400 Received: from lists.gnu.org ([2001:470:142::17]:50512) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVxIY-0004Ip-47 for submit@debbugs.gnu.org; Sun, 29 Jun 2025 15:02:44 -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 1uVxIS-0006NC-BL for bug-gnu-emacs@gnu.org; Sun, 29 Jun 2025 15:02:36 -0400 Received: from mail-24418.protonmail.ch ([109.224.244.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uVxIQ-0002Wn-0f for bug-gnu-emacs@gnu.org; Sun, 29 Jun 2025 15:02:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1751223750; x=1751482950; bh=bsLXr3v+6OdkeAQXhG29JUprlhp2vmZU6b440Rl6rEo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=GBtw5pPKkebHA2PF+ZETw6AT85z/7Zx9e32vhQRSfaVvrmnluhXMAH0/BaelWAMc/ +3bTiQkTvTwBLDO8YaCQjzLjH3uPMkxqgeBenb1OSX+Cf01Z+FgyKFqNkz5ffXcT4D MC0wSCqEWLy+4mNAm0ZV1qB1fAM6GIt2zmCqC/mImviXLGI5ReQ8JPGWtMiPjHvLmV JYgfCLOJIQ/+gRiDo6jdlShh7JASJKIO9hvT6DQUNHCoisKhGMakOoAkTU5Q7VAGMe 8rbvXMzGG5dfDttJApDBRAvlNBiNJugEhisVS/uk9f46Xh/jyKXInXdkX7+dgEX3eu 9ANJTZf9N7z5A== Date: Sun, 29 Jun 2025 19:02:27 +0000 To: Daniel Colascione From: Pip Cet Subject: Re: bug#78917: feature/igc [PATCH] Avoid chaining finalizers together Message-ID: <87ikkez800.fsf@protonmail.com> In-Reply-To: References: <87zfdsjx2y.fsf@gmail.com> <87ikkg2rpp.fsf@protonmail.com> <87ecv3k460.fsf@gmail.com> <878qlb1rb0.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 574e609f3684abaf31d358e64a3fd313fa2b51b3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=109.224.244.18; envelope-from=pipcet@protonmail.com; helo=mail-24418.protonmail.ch 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_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-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 Cc: 78917@debbugs.gnu.org, "Pip Cet via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" , Helmut Eller 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 (/) "Daniel Colascione" writes: > Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text edit= ors" writes: > >> "Helmut Eller" writes: >> >>> On Sat, Jun 28 2025, Pip Cet wrote: >>> >>>> "Helmut Eller" writes: >>>> >>>>> Lisp_Finalizers are currently chained together in a doubly linked lis= t. >>>>> This prevents them from being collected. I propose that we simply do= n't >>>>> use this list with MPS. >>>> >>>> See https://lists.gnu.org/archive/html/emacs-devel/2025-05/msg00468.ht= ml >>> >>> :-) >>> >>>> and bug#77338. >>> >>> It seems that the problem with finalizers as value in a weak hashtable >>> could be fixed by calling mark_and_sweep_weak_table_contents before >>> queue_doomed_finalizers as in the patch below. > > Ouch. That branch of the discussion of bug#77338 slipped past me. > Thanks for bringing it up. > Gut feeling is that the solution is some kind of iterated walk over > finalizers and weak tables until we reach a fixed point? Let me think > it over. Thanks, that'd be great! My approach was to do the combined iteration by keeping finalizers in a weak hash table (a weak set). 1. mark all weak hash tables, including the finalizer table, until we hit a fixed point 2. condemn unmarked finalizers; remember that somewhere 3. mark all condemned finalizers strongly 4. repeat step 1 5. sweep unmarked weak hash table entries (there are none in the finalizer table) 6. run condemned finalizers and remove them from the table However, I admit that using a weak hash table to keep the finalizers in is problematic, because we might have to shrink it at some point. Also, no working code here, so maybe my approach was entirely wrong. If we can fix this, we could change font finalization to use Lisp finalizers, I think. >> No, that's not the right fix: a finalizer function can still refer to >> weak hash tables (the finalizer itself is not a weak object), so we >> can't sweep the weak hash tables until all finalizers have been marked. >> >> This is solvable, but it requires more effort than exchanging those two >> calls. >> >> However, I'm not sure we should fix the traditional GC code to be better >> than what MPS can do :-) > > Emacs 31 is going to live a long time and igc won't be its default GC. Agreed. I'm just saying we don't need to define to the last detail how finalizers behave wrt weak hash tables, it's better if there is some slack there so other GC implementations can do their job. Similarly, we should probably deprecate key-and-value strongness in Emacs generally, and remove the hack that makes it "work" in feature/igc. Pip