From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 Apr 2022 18:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 54698@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.16490112728747 (code B ref -1); Sun, 03 Apr 2022 18:42:02 +0000 Received: (at submit) by debbugs.gnu.org; 3 Apr 2022 18:41:12 +0000 Received: from localhost ([127.0.0.1]:49510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nb5A0-0002H1-GV for submit@debbugs.gnu.org; Sun, 03 Apr 2022 14:41:12 -0400 Received: from lists.gnu.org ([209.51.188.17]:58212) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nb59y-0002Gt-JF for submit@debbugs.gnu.org; Sun, 03 Apr 2022 14:41:11 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38964) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nb59y-0004sa-2C for bug-gnu-emacs@gnu.org; Sun, 03 Apr 2022 14:41:10 -0400 Received: from mail229c50.megamailservers.eu ([91.136.10.239]:50956 helo=mail36c50.megamailservers.eu) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nb59s-0006Fn-CP for bug-gnu-emacs@gnu.org; Sun, 03 Apr 2022 14:41:09 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1649011259; bh=6Lald9jd/5vOctkEf3a7BH+lcAGUlOLAAh2/B/lSJNU=; h=From:Subject:Date:To:From; b=qSerqzb/+k6fvFo3NbTPhvVHns0Zj9NDz+h8C1b6U++v0W9Dapf0/FJZho2ViJiGs gcoYikUqDmn7VtclPXdbt9CYdgiT8GKTlW69nNHUjplzYRgewXWJeK65SKk+G7KEKA 3NOqeJ7KkPOBWBmDkK5xK42EKJKXjzIFkaqxscFo= Feedback-ID: mattiase@acm.or Received: from smtpclient.apple (c188-150-171-71.bredband.tele2.se [188.150.171.71]) (authenticated bits=0) by mail36c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 233Iev1E006086 for ; Sun, 3 Apr 2022 18:40:59 +0000 From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Content-Type: multipart/mixed; boundary="Apple-Mail=_3A69BF77-D790-4292-9ACE-B285B48060C6" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-Id: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> Date: Sun, 3 Apr 2022 20:40:57 +0200 X-Mailer: Apple Mail (2.3654.120.0.1.13) X-CTCH-RefID: str=0001.0A742F25.6249EA3B.0022, 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-Origin-Country: SE Received-SPF: softfail client-ip=91.136.10.239; envelope-from=mattiase@acm.org; helo=mail36c50.megamailservers.eu X-Spam_score_int: -11 X-Spam_score: -1.2 X-Spam_bar: - X-Spam_report: (-1.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.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: -2.3 (--) --Apple-Mail=_3A69BF77-D790-4292-9ACE-B285B48060C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The GC uses recursion to traverse data structures for marking which = imposes a limit to how big (or deeply nested) Lisp data structures can = be, and usually results in an immediate Emacs crash without warning when = that limit is exceeded. The attached patch replaces recursion with an explicit stack for most = common object types: conses, vectors, records, hash tables, symbols, = functions etc. Recursion remains for some less common types (buffers, = frames etc) but these are typically not used in quantities to cause a = problem. A side benefit is that GC becomes quite a bit faster as a result. Actual = workloads such as byte-compilation are consequently sped up by a small = but measurable amount. The patch is explicitly unfinished in some uninteresting respects to = make it easier to read; `process_mark_stack` needs reindenting. --Apple-Mail=_3A69BF77-D790-4292-9ACE-B285B48060C6 Content-Disposition: attachment; filename=gc-mark-stack.diff Content-Type: application/octet-stream; x-unix-mode=0644; name="gc-mark-stack.diff" Content-Transfer-Encoding: 7bit diff --git a/src/alloc.c b/src/alloc.c index b06dd943ba..b008f45c8c 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -6085,6 +6085,8 @@ maybe_garbage_collect (void) garbage_collect (); } +static inline bool mark_stack_empty_p (void); + /* Subroutine of Fgarbage_collect that does most of the work. */ void garbage_collect (void) @@ -6100,6 +6102,8 @@ garbage_collect (void) if (garbage_collection_inhibited) return; + eassert(mark_stack_empty_p ()); + /* Record this function, so it appears on the profiler's backtraces. */ record_in_backtrace (QAutomatic_GC, 0, 0); @@ -6222,6 +6226,8 @@ garbage_collect (void) mark_and_sweep_weak_table_contents (); eassert (weak_hash_tables == NULL); + eassert (mark_stack_empty_p ()); + gc_sweep (); unmark_main_thread (); @@ -6395,15 +6401,25 @@ mark_glyph_matrix (struct glyph_matrix *matrix) } } +/* Whether to remember a few of the last marked values for debugging. */ +#define GC_REMEMBER_LAST_MARKED 0 + +#if GC_REMEMBER_LAST_MARKED enum { LAST_MARKED_SIZE = 1 << 9 }; /* Must be a power of 2. */ Lisp_Object last_marked[LAST_MARKED_SIZE] EXTERNALLY_VISIBLE; static int last_marked_index; +#endif +/* Whether to enable the mark_object_loop_halt debugging feature. */ +#define GC_CDR_COUNT 0 + +#if GC_CDR_COUNT /* For debugging--call abort when we cdr down this many links of a list, in mark_object. In debugging, the call to abort will hit a breakpoint. Normally this is zero and the check never goes off. */ ptrdiff_t mark_object_loop_halt EXTERNALLY_VISIBLE; +#endif static void mark_vectorlike (union vectorlike_header *header) @@ -6457,19 +6473,6 @@ mark_char_table (struct Lisp_Vector *ptr, enum pvec_type pvectype) } } -NO_INLINE /* To reduce stack depth in mark_object. */ -static Lisp_Object -mark_compiled (struct Lisp_Vector *ptr) -{ - int i, size = ptr->header.size & PSEUDOVECTOR_SIZE_MASK; - - set_vector_marked (ptr); - for (i = 0; i < size; i++) - if (i != COMPILED_CONSTANTS) - mark_object (ptr->contents[i]); - return size > COMPILED_CONSTANTS ? ptr->contents[COMPILED_CONSTANTS] : Qnil; -} - /* Mark the chain of overlays starting at PTR. */ static void @@ -6622,63 +6625,115 @@ mark_window (struct Lisp_Vector *ptr) (w, mark_discard_killed_buffers (w->next_buffers)); } -static void -mark_hash_table (struct Lisp_Vector *ptr) -{ - struct Lisp_Hash_Table *h = (struct Lisp_Hash_Table *) ptr; - - mark_vectorlike (&h->header); - mark_object (h->test.name); - mark_object (h->test.user_hash_function); - mark_object (h->test.user_cmp_function); - /* If hash table is not weak, mark all keys and values. For weak - tables, mark only the vector and not its contents --- that's what - makes it weak. */ - if (NILP (h->weak)) - mark_object (h->key_and_value); - else +/* Entry of the mark stack. */ +struct mark_entry +{ + ptrdiff_t n; /* number of values, or 0 if a single value */ + union { + Lisp_Object value; /* when n = 0 */ + Lisp_Object *values; /* when n > 0 */ + } u; +}; + +/* This stack is used during marking for traversing data structures without + using C recursion. */ +struct mark_stack +{ + struct mark_entry *stack; /* base of stack */ + ptrdiff_t size; /* allocated size in entries */ + ptrdiff_t sp; /* current number of entries */ +}; + +static struct mark_stack mark_stk = {NULL, 0, 0}; + +static inline bool +mark_stack_empty_p (void) +{ + return mark_stk.sp <= 0; +} + +/* Pop and return a value from the mark stack (which must be nonempty). */ +static inline Lisp_Object +mark_stack_pop (void) +{ + eassume (!mark_stack_empty_p ()); + struct mark_entry *e = &mark_stk.stack[mark_stk.sp - 1]; + if (e->n == 0) /* single value */ { - eassert (h->next_weak == NULL); - h->next_weak = weak_hash_tables; - weak_hash_tables = h; - set_vector_marked (XVECTOR (h->key_and_value)); + --mark_stk.sp; + return e->u.value; } + /* Array of values: pop them left to right, which seems to be slightly + faster than right to left. */ + e->n--; + if (e->n == 0) + --mark_stk.sp; /* last value consumed */ + return (++e->u.values)[-1]; } -void -mark_objects (Lisp_Object *obj, ptrdiff_t n) +NO_INLINE static void +grow_mark_stack (void) { - for (ptrdiff_t i = 0; i < n; i++) - mark_object (obj[i]); + struct mark_stack *ms = &mark_stk; + eassert (ms->sp == ms->size); + ptrdiff_t min_incr = ms->sp == 0 ? 8192 : 1; + ptrdiff_t oldsize = ms->size; + ms->stack = xpalloc (ms->stack, &ms->size, min_incr, -1, sizeof *ms->stack); + eassert (ms->sp < ms->size); } -/* Determine type of generic Lisp_Object and mark it accordingly. +/* Push VALUE onto the mark stack. */ +static inline void +mark_stack_push_value (Lisp_Object value) +{ + if (mark_stk.sp >= mark_stk.size) + grow_mark_stack (); + mark_stk.stack[mark_stk.sp++] = (struct mark_entry){.n = 0, .u.value = value}; +} - This function implements a straightforward depth-first marking - algorithm and so the recursion depth may be very high (a few - tens of thousands is not uncommon). To minimize stack usage, - a few cold paths are moved out to NO_INLINE functions above. - In general, inlining them doesn't help you to gain more speed. */ +/* Push the N values at VALUES onto the mark stack. */ +static inline void +mark_stack_push_values (Lisp_Object *values, ptrdiff_t n) +{ + eassume (n >= 0); + if (n == 0) + return; + if (mark_stk.sp >= mark_stk.size) + grow_mark_stack (); + mark_stk.stack[mark_stk.sp++] = (struct mark_entry){.n = n, + .u.values = values}; +} -void -mark_object (Lisp_Object arg) +/* Traverse and mark objects on the mark stack above BASE_SP. + + Traversal is depth-first using the mark stack for most common + object types. Recursion is used for other types, in the hope that + they are rare enough that C stack usage is kept low. */ +static void +process_mark_stack (ptrdiff_t base_sp) { - register Lisp_Object obj; - void *po; #if GC_CHECK_MARKED_OBJECTS struct mem_node *m = NULL; #endif +#if GC_CDR_COUNT ptrdiff_t cdr_count = 0; +#endif - obj = arg; - loop: + eassume (mark_stk.sp >= base_sp && base_sp >= 0); - po = XPNTR (obj); + while (mark_stk.sp > base_sp) + { + // FIXME: reindent loop body + Lisp_Object obj = mark_stack_pop (); + mark_obj: ; + void *po = XPNTR (obj); if (PURE_P (po)) - return; + continue; +#if GC_REMEMBER_LAST_MARKED last_marked[last_marked_index++] = obj; last_marked_index &= LAST_MARKED_SIZE - 1; +#endif /* Perform some sanity checks on the objects marked here. Abort if we encounter an object we know is bogus. This increases GC time @@ -6781,16 +6836,6 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0) mark_buffer ((struct buffer *) ptr); break; - case PVEC_COMPILED: - /* Although we could treat this just like a vector, mark_compiled - returns the COMPILED_CONSTANTS element, which is marked at the - next iteration of goto-loop here. This is done to avoid a few - recursive calls to mark_object. */ - obj = mark_compiled (ptr); - if (!NILP (obj)) - goto loop; - break; - case PVEC_FRAME: mark_frame (ptr); break; @@ -6800,8 +6845,27 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0) break; case PVEC_HASH_TABLE: - mark_hash_table (ptr); - break; + { + struct Lisp_Hash_Table *h = (struct Lisp_Hash_Table *)ptr; + ptrdiff_t size = ptr->header.size & PSEUDOVECTOR_SIZE_MASK; + set_vector_marked (ptr); + mark_stack_push_values (ptr->contents, size); + mark_stack_push_value (h->test.name); + mark_stack_push_value (h->test.user_hash_function); + mark_stack_push_value (h->test.user_cmp_function); + if (NILP (h->weak)) + mark_stack_push_value (h->key_and_value); + else + { + /* For weak tables, mark only the vector and not its + contents --- that's what makes it weak. */ + eassert (h->next_weak == NULL); + h->next_weak = weak_hash_tables; + weak_hash_tables = h; + set_vector_marked (XVECTOR (h->key_and_value)); + } + break; + } case PVEC_CHAR_TABLE: case PVEC_SUB_CHAR_TABLE: @@ -6828,11 +6892,11 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0) { set_vector_marked (ptr); struct Lisp_Subr *subr = XSUBR (obj); - mark_object (subr->native_intspec); - mark_object (subr->command_modes); - mark_object (subr->native_comp_u); - mark_object (subr->lambda_list); - mark_object (subr->type); + mark_stack_push_value (subr->native_intspec); + mark_stack_push_value (subr->command_modes); + mark_stack_push_value (subr->native_comp_u); + mark_stack_push_value (subr->lambda_list); + mark_stack_push_value (subr->type); } #endif break; @@ -6841,9 +6905,16 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0) emacs_abort (); default: - /* A regular vector, or a pseudovector needing no special - treatment. */ - mark_vectorlike (&ptr->header); + { + /* A regular vector or pseudovector needing no special + treatment. */ + ptrdiff_t size = ptr->header.size; + if (size & PSEUDOVECTOR_FLAG) + size &= PSEUDOVECTOR_SIZE_MASK; + set_vector_marked (ptr); + mark_stack_push_values (ptr->contents, size); + } + break; } } break; @@ -6858,16 +6929,16 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0) set_symbol_marked (ptr); /* Attempt to catch bogus objects. */ eassert (valid_lisp_object_p (ptr->u.s.function)); - mark_object (ptr->u.s.function); - mark_object (ptr->u.s.plist); + mark_stack_push_value (ptr->u.s.function); + mark_stack_push_value (ptr->u.s.plist); switch (ptr->u.s.redirect) { - case SYMBOL_PLAINVAL: mark_object (SYMBOL_VAL (ptr)); break; + case SYMBOL_PLAINVAL: mark_stack_push_value (SYMBOL_VAL (ptr)); break; case SYMBOL_VARALIAS: { Lisp_Object tem; XSETSYMBOL (tem, SYMBOL_ALIAS (ptr)); - mark_object (tem); + mark_stack_push_value (tem); break; } case SYMBOL_LOCALIZED: @@ -6898,19 +6969,20 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0) break; CHECK_ALLOCATED_AND_LIVE (live_cons_p, MEM_TYPE_CONS); set_cons_marked (ptr); - /* If the cdr is nil, avoid recursion for the car. */ - if (NILP (ptr->u.s.u.cdr)) + /* Avoid growing the stack if the cdr is nil. + In any case, make sure the car is expanded first. */ + if (!NILP (ptr->u.s.u.cdr)) { - obj = ptr->u.s.car; - cdr_count = 0; - goto loop; + mark_stack_push_value (ptr->u.s.u.cdr); +#if GC_CDR_COUNT + cdr_count++; + if (cdr_count == mark_object_loop_halt) + emacs_abort (); +#endif } - mark_object (ptr->u.s.car); - obj = ptr->u.s.u.cdr; - cdr_count++; - if (cdr_count == mark_object_loop_halt) - emacs_abort (); - goto loop; + /* Speedup hack for the common case (successive list elements). */ + obj = ptr->u.s.car; + goto mark_obj; } case Lisp_Float: @@ -6930,11 +7002,29 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0) emacs_abort (); } + } + #undef CHECK_LIVE #undef CHECK_ALLOCATED #undef CHECK_ALLOCATED_AND_LIVE } +void +mark_object (Lisp_Object obj) +{ + ptrdiff_t sp = mark_stk.sp; + mark_stack_push_value (obj); + process_mark_stack (sp); +} + +void +mark_objects (Lisp_Object *objs, ptrdiff_t n) +{ + ptrdiff_t sp = mark_stk.sp; + mark_stack_push_values (objs, n); + process_mark_stack (sp); +} + /* Mark the Lisp pointers in the terminal objects. Called by Fgarbage_collect. */ -- 2.32.0 (Apple Git-132) --Apple-Mail=_3A69BF77-D790-4292-9ACE-B285B48060C6-- From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Apr 2022 11:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164907011916601 (code B ref 54698); Mon, 04 Apr 2022 11:02:02 +0000 Received: (at 54698) by debbugs.gnu.org; 4 Apr 2022 11:01:59 +0000 Received: from localhost ([127.0.0.1]:50621 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbKT9-0004JS-ED for submit@debbugs.gnu.org; Mon, 04 Apr 2022 07:01:59 -0400 Received: from quimby.gnus.org ([95.216.78.240]:42508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbKT7-0004EX-IA for 54698@debbugs.gnu.org; Mon, 04 Apr 2022 07:01:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: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=fiLdl4fz/s2T+54X9CHiVZCPrkVm/CUoLACLQS7IY8g=; b=pcyhKaIEwKr8FcEJKyFxZJEFlo mplMSnIA0EsPx+gEMTU0KVft03MXDq23pZ/oqwf7wOsLDZl9wTl+0UEn3jXVDyPsqCh10A5XKPnpQ Il7tl0BlkRynaRsGK7AZCwQ7oDJa9YJXQ9OOjf+W+KkMmUpux7FkVqsTg43FSKl3pVlo=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nbKSy-0004d0-9O; Mon, 04 Apr 2022 13:01:50 +0200 From: Lars Ingebrigtsen References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> Date: Mon, 04 Apr 2022 13:01:46 +0200 In-Reply-To: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Sun, 3 Apr 2022 20:40:57 +0200") Message-ID: <8735itglid.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= writes: > The attached patch replaces recursion with an explicit stack for most > common object types: conses, vectors, records, hash tables, symbols, > functions etc. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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 (---) Mattias Engdeg=C3=A5rd writes: > The attached patch replaces recursion with an explicit stack for most > common object types: conses, vectors, records, hash tables, symbols, > functions etc. That's wonderful -- I guess this fixes the segfaults we're seeing with structures that recurse on the car? Is there a max stack size? --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Apr 2022 11:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Lars Ingebrigtsen Cc: 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164907099819742 (code B ref 54698); Mon, 04 Apr 2022 11:17:02 +0000 Received: (at 54698) by debbugs.gnu.org; 4 Apr 2022 11:16:38 +0000 Received: from localhost ([127.0.0.1]:50636 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbKhK-00058M-AG for submit@debbugs.gnu.org; Mon, 04 Apr 2022 07:16:38 -0400 Received: from mail1454c50.megamailservers.eu ([91.136.14.54]:42978 helo=mail266c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbKhH-000587-TF for 54698@debbugs.gnu.org; Mon, 04 Apr 2022 07:16:37 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1649070989; bh=3KY586FtyJ0qTEU8vtOiVNiU+kyeBdTG+wD2nUdohaw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=k5S8M1SIcinigoRr0McDTxlawr23uLbE7JgblcEpoQWgHUZjigAgrVVIN3Sm9sFBn lfyukanL80JCbB01RhLwhK9nG8xDQzk80YKAnd3fabMc6Ai23roFzFCQCG8bOPTxKR cGofptpUaLX0CIF6VgbAag8JAqkFOHMtpbdYZnXU= Feedback-ID: mattiase@acm.or Received: from smtpclient.apple (c-b952e353.032-75-73746f71.bbcust.telenor.se [83.227.82.185]) (authenticated bits=0) by mail266c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 234BGQBs018060; Mon, 4 Apr 2022 11:16:28 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= In-Reply-To: <8735itglid.fsf@gnus.org> Date: Mon, 4 Apr 2022 13:16:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-CTCH-RefID: str=0001.0A742F21.624AD38D.0002, 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-Origin-Country: SE X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 4 apr. 2022 kl. 13.01 skrev Lars Ingebrigtsen : > That's wonderful -- I guess this fixes the segfaults we're seeing with > structures that recurse on the car? Yes, it should. Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.0 T_SCC_BODY_TEXT_LINE No description available. 0.3 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS 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 (/) 4 apr. 2022 kl. 13.01 skrev Lars Ingebrigtsen : > That's wonderful -- I guess this fixes the segfaults we're seeing with > structures that recurse on the car? Yes, it should. > Is there a max stack size? No, the mark stack grows as needed. I see no reason to limit the size = since it's going to be much smaller than the size of the heap being = traced in any case. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Apr 2022 11:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164907176120902 (code B ref 54698); Mon, 04 Apr 2022 11:30:02 +0000 Received: (at 54698) by debbugs.gnu.org; 4 Apr 2022 11:29:21 +0000 Received: from localhost ([127.0.0.1]:50657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbKtc-0005R4-PK for submit@debbugs.gnu.org; Mon, 04 Apr 2022 07:29:20 -0400 Received: from quimby.gnus.org ([95.216.78.240]:42724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbKtb-0005Ql-26 for 54698@debbugs.gnu.org; Mon, 04 Apr 2022 07:29:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: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=tv7arWYdY/9QR6vxhv/WL+xFJPLE8yY6EOnsEQWPxHs=; b=A+fgMas9lyfOoIa21wCBnY84E9 sKpgptDQX+BUXXaRUYaZbVrLPP2Xhs2CSjvdVhWIEILA6IlI1qAKzzw5Lha/NCLLXmQLu/oXYtakH HcIrEtaCvysDjj3Ex4/HdJQTWoDF1WA6q2l8ijYM2AZWU0FyyyIFoyBEXC+TyhnxuVp8=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nbKtS-0004qm-3B; Mon, 04 Apr 2022 13:29:12 +0200 From: Lars Ingebrigtsen References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> Date: Mon, 04 Apr 2022 13:29:09 +0200 In-Reply-To: <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Mon, 4 Apr 2022 13:16:26 +0200") Message-ID: <87y20lf5oa.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= writes: >> Is there a max stack size? > > No, the mark stack grows as needed. I see no reason to limit the size > since it's going to be much smaller than the size of the heap being > traced in any case. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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 (---) Mattias Engdeg=C3=A5rd writes: >> Is there a max stack size? > > No, the mark stack grows as needed. I see no reason to limit the size > since it's going to be much smaller than the size of the heap being > traced in any case. Sounds good. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Apr 2022 11:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164907189927207 (code B ref 54698); Mon, 04 Apr 2022 11:32:01 +0000 Received: (at 54698) by debbugs.gnu.org; 4 Apr 2022 11:31:39 +0000 Received: from localhost ([127.0.0.1]:50666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbKvr-00074a-Dl for submit@debbugs.gnu.org; Mon, 04 Apr 2022 07:31:39 -0400 Received: from quimby.gnus.org ([95.216.78.240]:42742) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbKvp-0006yN-C1 for 54698@debbugs.gnu.org; Mon, 04 Apr 2022 07:31:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References: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=moFk/GYa5HCjWOQyqZyj8fs8sSJPsPLMPRKQKIV5QHA=; b=c2QZnW4jH7EsoqogOsWRnSr9Wi lIkX01BuckCUkiBa7lShKzGj/6ifvIC5fiqacsX2vrprChitHweWm1PYwHixa83WqyfH7dD/dsT3m iaKbJ2eKIR34YST3t9AoBvgXOcsfQS6jqYju/aO87NVgJGX9wYELC42mclbFWXgSENSk=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nbKvg-0004rM-LF; Mon, 04 Apr 2022 13:31:30 +0200 From: Lars Ingebrigtsen References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <87y20lf5oa.fsf@gnus.org> Date: Mon, 04 Apr 2022 13:31:27 +0200 In-Reply-To: <87y20lf5oa.fsf@gnus.org> (Lars Ingebrigtsen's message of "Mon, 04 Apr 2022 13:29:09 +0200") Message-ID: <87pmlxf5kg.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: (bug#31362 and bug#46900 should probably be closed after applying this patch, I guess.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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 (---) (bug#31362 and bug#46900 should probably be closed after applying this patch, I guess.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Apr 2022 11:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: larsi@gnus.org, 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164907233630161 (code B ref 54698); Mon, 04 Apr 2022 11:39:01 +0000 Received: (at 54698) by debbugs.gnu.org; 4 Apr 2022 11:38:56 +0000 Received: from localhost ([127.0.0.1]:50675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbL2u-0007qP-5C for submit@debbugs.gnu.org; Mon, 04 Apr 2022 07:38:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbL2r-0007qA-OT for 54698@debbugs.gnu.org; Mon, 04 Apr 2022 07:38:55 -0400 Received: from [2001:470:142:3::e] (port=58438 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nbL2m-0006CO-A1; Mon, 04 Apr 2022 07:38:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=2X6hLpRB1iRWq2tRTNIRnbhCLr/Umkf1Ns3LcDM4lwU=; b=Cm/zmDzNYINVziSnRa5t FistC+N9iQuCKZLpQxc/4OvDNMGXHN+4oC8GPTjlc0bmybS73UTvN+uh1Uexm10jP8tyK3dF0rPu/ 4yek0Dt7bA4Zg+NE7E8Zv7/bKQZRuHpXtH3AXTlHRBRkhW+x31HAQu67M0JkZebnnKOSxX8pSxiA9 VIdKld2Tr4vU7biqFl7yNhCsKt66CDU+YGrcQh9ld8i/kM4XVvDlsoDdgxliIWIRKxrNLl/Nypg+N 6ETslvHcUGwdynlPwzbn0p43uJ1/nLw108mUvbDsD39M+akMpvixJd0WRULVR/cS1htzyHp3UBps4 nM6yemWF/+UD3w==; Received: from [87.69.77.57] (port=1891 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nbL2g-0000o6-Kp; Mon, 04 Apr 2022 07:38:46 -0400 Date: Mon, 04 Apr 2022 14:38:44 +0300 Message-Id: <834k39f58b.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Mon, 4 Apr 2022 13:16:26 +0200) References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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, 4 Apr 2022 13:16:26 +0200 > Cc: 54698@debbugs.gnu.org > > > Is there a max stack size? > > No, the mark stack grows as needed. I see no reason to limit the size since it's going to be much smaller than the size of the heap being traced in any case. What happens with data that GC relocates, like when it relocates and compacts string data? If the relocated data is allocated on the heap after the simulated stack, the original string data, which is now free memory, will be "trapped" behind the simulated stack, and 'free' will be unable to return it to the OS. This could make the memory footprint of Emacs larger than it could be. Was this aspect considered and audited/tested? From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Apr 2022 11:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: larsi@gnus.org, 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164907348332033 (code B ref 54698); Mon, 04 Apr 2022 11:59:02 +0000 Received: (at 54698) by debbugs.gnu.org; 4 Apr 2022 11:58:03 +0000 Received: from localhost ([127.0.0.1]:50700 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbLLP-0008Ka-Gf for submit@debbugs.gnu.org; Mon, 04 Apr 2022 07:58:03 -0400 Received: from mail18c50.megamailservers.eu ([91.136.10.28]:54148) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbLLM-0008K8-Fl for 54698@debbugs.gnu.org; Mon, 04 Apr 2022 07:58:01 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1649073477; bh=r6GkfQs+uk8XDaiFO0rD8xtLht1ebW+SdDqP472aZ8I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=oxZM6GiE6CcqVMMUbjZJvdbcIzC661AFYIDS6j6aScXcX4p+FGI7Bv4yih+8CaT8S BDI9tG0JIBHjwlJt2StoNqKrTnDmysW8UNx4ViDNDqY4xFsHDMxk9ySfdUzffCkIcp GjjylB0ICEETV17vqA6Tggq5uBCZn2hcauJjc8z8= Feedback-ID: mattiase@acm.or Received: from smtpclient.apple (c-b952e353.032-75-73746f71.bbcust.telenor.se [83.227.82.185]) (authenticated bits=0) by mail18c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 234BvtiY020843; Mon, 4 Apr 2022 11:57:56 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= In-Reply-To: <834k39f58b.fsf@gnu.org> Date: Mon, 4 Apr 2022 13:57:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <834k39f58b.fsf@gnu.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-CTCH-RefID: str=0001.0A742F1F.624ADD45.007F, 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-Origin-Country: SE 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 (/) 4 apr. 2022 kl. 13.38 skrev Eli Zaretskii : > What happens with data that GC relocates, like when it relocates and > compacts string data? If the relocated data is allocated on the heap > after the simulated stack, the original string data, which is now free > memory, will be "trapped" behind the simulated stack, and 'free' will > be unable to return it to the OS. This could make the memory > footprint of Emacs larger than it could be. That effect is unlikely to be visible. I don't think a single (and not = very big) allocation would contribute materially to heap fragmentation, = given the amount of allocation being made all the time. (But prove me = wrong!) > Was this aspect considered and audited/tested? Do you have a test case? From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Apr 2022 12:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: larsi@gnus.org, 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164907511410428 (code B ref 54698); Mon, 04 Apr 2022 12:26:02 +0000 Received: (at 54698) by debbugs.gnu.org; 4 Apr 2022 12:25:14 +0000 Received: from localhost ([127.0.0.1]:50741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbLli-0002i8-35 for submit@debbugs.gnu.org; Mon, 04 Apr 2022 08:25:14 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55282) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbLlg-0002hq-Vi for 54698@debbugs.gnu.org; Mon, 04 Apr 2022 08:25:13 -0400 Received: from [2001:470:142:3::e] (port=59422 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nbLlb-0006R3-IQ; Mon, 04 Apr 2022 08:25:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Z0K83FM84Q4QOxf8zr5HDn2hoeiV4s70wVOhMbSBssw=; b=i7POq6J11ZSQeYS9UBvR c1+9yIEsJFeFrtKJpMOXPDiQRfj/svGbCBiqklRUJJDedF/6HbDuhDc8BA/gZY4lgK4VbKSn3wJEF ejhNARJA0a1PfuWFDwQz+K3fhThRtHMzp5gJ3LEHdr47KP8juDKp+ba7yD1zjoYB0dl3FIH/3gJQt lV6d34y1Uf+KlrnMvZkaMA2yxxs7yC1cBIpsgeGZTPqRsVtK/gKl5+sD70qw0YjkJf4UFE4k70l42 6R71AQrti4yNoyEfoUuli4le+p0vp/oD10R2JHl3rAC0qz3iklPBa8ROhCnd4KbCcleKKC33/fNfj Hcln6P8Oq/sXVw==; Received: from [87.69.77.57] (port=4832 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nbLlZ-0007KH-E2; Mon, 04 Apr 2022 08:25:07 -0400 Date: Mon, 04 Apr 2022 15:25:07 +0300 Message-Id: <83y20ldoik.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Mon, 4 Apr 2022 13:57:54 +0200) References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <834k39f58b.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 (---) > Feedback-ID:mattiase@acm.or > From: Mattias Engdegård > Date: Mon, 4 Apr 2022 13:57:54 +0200 > Cc: larsi@gnus.org, 54698@debbugs.gnu.org > > 4 apr. 2022 kl. 13.38 skrev Eli Zaretskii : > > > What happens with data that GC relocates, like when it relocates and > > compacts string data? If the relocated data is allocated on the heap > > after the simulated stack, the original string data, which is now free > > memory, will be "trapped" behind the simulated stack, and 'free' will > > be unable to return it to the OS. This could make the memory > > footprint of Emacs larger than it could be. > > That effect is unlikely to be visible. I don't think a single (and not very big) allocation would contribute materially to heap fragmentation, given the amount of allocation being made all the time. (But prove me wrong!) I don't need to prove you wrong: if the problem is real, we will hear about that soon enough. In principle, even a small allocation can prevent a large free portion of the arena from being returned to the OS. And Lisp strings nowadays tend to be a legion and some quite large in some applications, because many packages abuse them (instead of using temporary buffers). From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Apr 2022 14:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.1649082789598 (code B ref 54698); Mon, 04 Apr 2022 14:34:01 +0000 Received: (at 54698) by debbugs.gnu.org; 4 Apr 2022 14:33:09 +0000 Received: from localhost ([127.0.0.1]:52602 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbNlV-00009a-2B for submit@debbugs.gnu.org; Mon, 04 Apr 2022 10:33:09 -0400 Received: from mx.sdf.org ([205.166.94.24]:60194) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbNlT-00009Q-Uq for 54698@debbugs.gnu.org; Mon, 04 Apr 2022 10:33:08 -0400 Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 234EWpQU014842 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 4 Apr 2022 14:32:52 GMT From: Andrea Corallo References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> Date: Mon, 04 Apr 2022 14:32:51 +0000 In-Reply-To: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Sun, 3 Apr 2022 20:40:57 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (-) Mattias Engdeg=C3=A5rd writes: > The GC uses recursion to traverse data structures for marking which > imposes a limit to how big (or deeply nested) Lisp data structures can > be, and usually results in an immediate Emacs crash without warning > when that limit is exceeded. > > The attached patch replaces recursion with an explicit stack for most > common object types: conses, vectors, records, hash tables, symbols, > functions etc. Recursion remains for some less common types (buffers, > frames etc) but these are typically not used in quantities to cause a > problem. > > A side benefit is that GC becomes quite a bit faster as a result. Actual = workloads such as byte-compilation are consequently sped up by a small but = measurable amount. Hi Mattias, do you have any other performance measure for cases different than the one mentioned? Thanks Andrea From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Apr 2022 14:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Andrea Corallo Cc: 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.16490832141597 (code B ref 54698); Mon, 04 Apr 2022 14:41:01 +0000 Received: (at 54698) by debbugs.gnu.org; 4 Apr 2022 14:40:14 +0000 Received: from localhost ([127.0.0.1]:52611 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbNsM-0000Pg-4f for submit@debbugs.gnu.org; Mon, 04 Apr 2022 10:40:14 -0400 Received: from mail1468c50.megamailservers.eu ([91.136.14.68]:36224 helo=mail268c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbNsJ-0000P7-F0 for 54698@debbugs.gnu.org; Mon, 04 Apr 2022 10:40:12 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1649083204; bh=izHR3oLbIIdrLp6QPoG/idW0GXiaCXZeU+QZTT1uJeU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ZiT4xymFPX6kR4YvMLqdUvlHAqpA7r87/qjahiJ3DTSMRDIwdDu2G6HFiQJECeQWd EMWCJDTUa89hB2earVE2PGnMcIFThHILuJxNn+l4uCqXsTC05X8k5QJynuqW+eFzsU oKTl6oAHu/3hRwNqZzbuFxlEZS+oLjPPPvyIBNIE= Feedback-ID: mattiase@acm.or Received: from smtpclient.apple (c-b952e353.032-75-73746f71.bbcust.telenor.se [83.227.82.185]) (authenticated bits=0) by mail268c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 234Edwgb020166; Mon, 4 Apr 2022 14:40:03 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= In-Reply-To: Date: Mon, 4 Apr 2022 16:39:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-CTCH-RefID: str=0001.0A742F17.624B0344.0059, 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-Origin-Country: SE X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 4 apr. 2022 kl. 16.32 skrev Andrea Corallo : > do you have any other performance measure for cases different than the > one mentioned? Well, there is the usual collection of special-purpose benchmarks, and I also timed the GC after a precise set of interactions involving scrolling through xdisp.c and typecore.ml, as well as running m [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.0 T_SCC_BODY_TEXT_LINE No description available. 0.3 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS 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 (/) 4 apr. 2022 kl. 16.32 skrev Andrea Corallo : > do you have any other performance measure for cases different than the > one mentioned? Well, there is the usual collection of special-purpose benchmarks, and I = also timed the GC after a precise set of interactions involving = scrolling through xdisp.c and typecore.ml, as well as running magit. And = ran Relint, and a few more things I can't remember. The numbers were all = largely consistent, but I encourage you to run your fav workload. Anything particular on your mind? From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Apr 2022 15:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164908707711115 (code B ref 54698); Mon, 04 Apr 2022 15:45:01 +0000 Received: (at 54698) by debbugs.gnu.org; 4 Apr 2022 15:44:37 +0000 Received: from localhost ([127.0.0.1]:52717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbOsf-0002tD-Je for submit@debbugs.gnu.org; Mon, 04 Apr 2022 11:44:37 -0400 Received: from mx.sdf.org ([205.166.94.24]:51247) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbOsd-0002t2-NZ for 54698@debbugs.gnu.org; Mon, 04 Apr 2022 11:44:36 -0400 Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 234FiWL3008013 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 4 Apr 2022 15:44:32 GMT From: Andrea Corallo References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> Date: Mon, 04 Apr 2022 15:44:32 +0000 In-Reply-To: ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Mon, 4 Apr 2022 16:39:58 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (-) Mattias Engdeg=C3=A5rd writes: > 4 apr. 2022 kl. 16.32 skrev Andrea Corallo : > >> do you have any other performance measure for cases different than the >> one mentioned? > > Well, there is the usual collection of special-purpose benchmarks, and > I also timed the GC after a precise set of interactions involving > scrolling through xdisp.c and typecore.ml, as well as running > magit. And ran Relint, and a few more things I can't remember. The > numbers were all largely consistent, but I encourage you to run your > fav workload. > > Anything particular on your mind? We have some benchmarks in elisp-benchmarks that is GC bounded (IIRC nbody at least), I guess would be worth running. Thanks Andrea From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Apr 2022 16:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Andrea Corallo Cc: 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164908831114353 (code B ref 54698); Mon, 04 Apr 2022 16:06:01 +0000 Received: (at 54698) by debbugs.gnu.org; 4 Apr 2022 16:05:11 +0000 Received: from localhost ([127.0.0.1]:52760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbPCZ-0003jQ-DW for submit@debbugs.gnu.org; Mon, 04 Apr 2022 12:05:11 -0400 Received: from mail1445c50.megamailservers.eu ([91.136.14.45]:51602 helo=mail265c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbPCV-0003iT-Ng for 54698@debbugs.gnu.org; Mon, 04 Apr 2022 12:05:10 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1649088300; bh=OZ5yv9wFE20545dvrxQ1XNLOB2I0wvvJUOQD7WSbLdA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=PYtwEkUcqyGZncFhflsc8r0arVWTmQTsa8wk8POzJ9VOcP8QOyrUWMA3qJWru4mK5 K6VfNKBDoax18WALKDsXZXjz29GLgqwoxiPQ3M6xNAVMVJQtwmJ2KTYLs3c676WQs4 MrupngGuajag0iSLfjcJ6LAfhbDD9x1ZzI2+xw9g= Feedback-ID: mattiase@acm.or Received: from smtpclient.apple (c-b952e353.032-75-73746f71.bbcust.telenor.se [83.227.82.185]) (authenticated bits=0) by mail265c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 234G4udS022817; Mon, 4 Apr 2022 16:04:59 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= In-Reply-To: Date: Mon, 4 Apr 2022 18:04:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9E8C13E8-3803-4F1C-8EA0-029D71A8C291@acm.org> References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-CTCH-RefID: str=0001.0A742F19.624B172C.004C, 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-Origin-Country: SE X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 4 apr. 2022 kl. 17.44 skrev Andrea Corallo : > We have some benchmarks in elisp-benchmarks that is GC bounded (IIRC > nbody at least), I guess would be worth running. Go for it! I ran another float-intensive benchmark and got a speedup of 2.6 % which is more than I hoped for given that tracing floats isn't really affected much by the change from recursion to stack [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.0 T_SCC_BODY_TEXT_LINE No description available. 0.3 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS 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 (/) 4 apr. 2022 kl. 17.44 skrev Andrea Corallo : > We have some benchmarks in elisp-benchmarks that is GC bounded (IIRC > nbody at least), I guess would be worth running. Go for it! I ran another float-intensive benchmark and got a speedup of = 2.6 % which is more than I hoped for given that tracing floats isn't = really affected much by the change from recursion to stack as they have = no subcomponents that need tracing. And naturally this is all just some new go-fast stripes on the pig (and, = more importantly, iron railings preventing it from going down the = cliff), not the racehorse we really want. From unknown Sun Jun 22 00:23:16 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: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Subject: bug#54698: closed (Re: bug#54698: non-recursive GC marking [PATCH]) Message-ID: References: <7035D38C-F6AF-4B10-A398-32CB3EFCA84E@acm.org> <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> X-Gnu-PR-Message: they-closed 54698 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: patch Reply-To: 54698@debbugs.gnu.org Date: Mon, 04 Apr 2022 17:19:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1649092742-25011-1" This is a multi-part message in MIME format... ------------=_1649092742-25011-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #54698: non-recursive GC marking [PATCH] 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 54698@debbugs.gnu.org. --=20 54698: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D54698 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1649092742-25011-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 54698-done) by debbugs.gnu.org; 4 Apr 2022 17:18:45 +0000 Received: from localhost ([127.0.0.1]:52833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbQLl-0006Ug-2O for submit@debbugs.gnu.org; Mon, 04 Apr 2022 13:18:45 -0400 Received: from mail1466c50.megamailservers.eu ([91.136.14.66]:55314 helo=mail268c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbQLi-0006UE-82 for 54698-done@debbugs.gnu.org; Mon, 04 Apr 2022 13:18:43 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1649092715; bh=5ES+penBsIjo+V3LRDPcvcLoR2uqbG7E7OIYVYAwp+g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=FgI7Q6h3JVCCRwycDwqAgL72oid6gS3GV7spP/xZsDbYFALjJOzSpCCKVhK+7kQc2 XXzAj7HByzFoWmiIjGgXsq8yXTlj79+gsKXJzdjZ25WvrfmQtcRbGiS+kp7lAEl1iq XxGv7ejx/PsKA0rGC7jyXIZr6J4GDzttcKZnSj6E= Feedback-ID: mattiase@acm.or Received: from smtpclient.apple (c-b952e353.032-75-73746f71.bbcust.telenor.se [83.227.82.185]) (authenticated bits=0) by mail268c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 234HIWIR002495; Mon, 4 Apr 2022 17:18:34 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: bug#54698: non-recursive GC marking [PATCH] From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: <83y20ldoik.fsf@gnu.org> Date: Mon, 4 Apr 2022 19:18:31 +0200 Content-Transfer-Encoding: 7bit Message-Id: <7035D38C-F6AF-4B10-A398-32CB3EFCA84E@acm.org> References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <834k39f58b.fsf@gnu.org> <83y20ldoik.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3654.120.0.1.13) X-CTCH-RefID: str=0001.0A742F26.624B286B.0054, 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-Origin-Country: SE X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 4 apr. 2022 kl. 14.25 skrev Eli Zaretskii : > I don't need to prove you wrong: if the problem is real, we will hear > about that soon enough. Yes, you are probably right about that. Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.0 T_SCC_BODY_TEXT_LINE No description available. 0.3 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS X-Debbugs-Envelope-To: 54698-done Cc: Lars Ingebrigtsen , 54698-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: -0.0 (/) 4 apr. 2022 kl. 14.25 skrev Eli Zaretskii : > I don't need to prove you wrong: if the problem is real, we will hear > about that soon enough. Yes, you are probably right about that. 4 apr. 2022 kl. 13.31 skrev Lars Ingebrigtsen : > (bug#31362 and bug#46900 should probably be closed after applying this > patch, I guess.) Thanks, will do. Pushed to master (after tidying up). ------------=_1649092742-25011-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 3 Apr 2022 18:41:12 +0000 Received: from localhost ([127.0.0.1]:49510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nb5A0-0002H1-GV for submit@debbugs.gnu.org; Sun, 03 Apr 2022 14:41:12 -0400 Received: from lists.gnu.org ([209.51.188.17]:58212) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nb59y-0002Gt-JF for submit@debbugs.gnu.org; Sun, 03 Apr 2022 14:41:11 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38964) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nb59y-0004sa-2C for bug-gnu-emacs@gnu.org; Sun, 03 Apr 2022 14:41:10 -0400 Received: from mail229c50.megamailservers.eu ([91.136.10.239]:50956 helo=mail36c50.megamailservers.eu) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nb59s-0006Fn-CP for bug-gnu-emacs@gnu.org; Sun, 03 Apr 2022 14:41:09 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1649011259; bh=6Lald9jd/5vOctkEf3a7BH+lcAGUlOLAAh2/B/lSJNU=; h=From:Subject:Date:To:From; b=qSerqzb/+k6fvFo3NbTPhvVHns0Zj9NDz+h8C1b6U++v0W9Dapf0/FJZho2ViJiGs gcoYikUqDmn7VtclPXdbt9CYdgiT8GKTlW69nNHUjplzYRgewXWJeK65SKk+G7KEKA 3NOqeJ7KkPOBWBmDkK5xK42EKJKXjzIFkaqxscFo= Feedback-ID: mattiase@acm.or Received: from smtpclient.apple (c188-150-171-71.bredband.tele2.se [188.150.171.71]) (authenticated bits=0) by mail36c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 233Iev1E006086 for ; Sun, 3 Apr 2022 18:40:59 +0000 From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= Content-Type: multipart/mixed; boundary="Apple-Mail=_3A69BF77-D790-4292-9ACE-B285B48060C6" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: non-recursive GC marking [PATCH] Message-Id: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> Date: Sun, 3 Apr 2022 20:40:57 +0200 To: bug-gnu-emacs@gnu.org X-Mailer: Apple Mail (2.3654.120.0.1.13) X-CTCH-RefID: str=0001.0A742F25.6249EA3B.0022, 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-Origin-Country: SE Received-SPF: softfail client-ip=91.136.10.239; envelope-from=mattiase@acm.org; helo=mail36c50.megamailservers.eu X-Spam_score_int: -11 X-Spam_score: -1.2 X-Spam_bar: - X-Spam_report: (-1.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) 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.3 (--) --Apple-Mail=_3A69BF77-D790-4292-9ACE-B285B48060C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The GC uses recursion to traverse data structures for marking which = imposes a limit to how big (or deeply nested) Lisp data structures can = be, and usually results in an immediate Emacs crash without warning when = that limit is exceeded. The attached patch replaces recursion with an explicit stack for most = common object types: conses, vectors, records, hash tables, symbols, = functions etc. Recursion remains for some less common types (buffers, = frames etc) but these are typically not used in quantities to cause a = problem. A side benefit is that GC becomes quite a bit faster as a result. Actual = workloads such as byte-compilation are consequently sped up by a small = but measurable amount. The patch is explicitly unfinished in some uninteresting respects to = make it easier to read; `process_mark_stack` needs reindenting. --Apple-Mail=_3A69BF77-D790-4292-9ACE-B285B48060C6 Content-Disposition: attachment; filename=gc-mark-stack.diff Content-Type: application/octet-stream; x-unix-mode=0644; name="gc-mark-stack.diff" Content-Transfer-Encoding: 7bit diff --git a/src/alloc.c b/src/alloc.c index b06dd943ba..b008f45c8c 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -6085,6 +6085,8 @@ maybe_garbage_collect (void) garbage_collect (); } +static inline bool mark_stack_empty_p (void); + /* Subroutine of Fgarbage_collect that does most of the work. */ void garbage_collect (void) @@ -6100,6 +6102,8 @@ garbage_collect (void) if (garbage_collection_inhibited) return; + eassert(mark_stack_empty_p ()); + /* Record this function, so it appears on the profiler's backtraces. */ record_in_backtrace (QAutomatic_GC, 0, 0); @@ -6222,6 +6226,8 @@ garbage_collect (void) mark_and_sweep_weak_table_contents (); eassert (weak_hash_tables == NULL); + eassert (mark_stack_empty_p ()); + gc_sweep (); unmark_main_thread (); @@ -6395,15 +6401,25 @@ mark_glyph_matrix (struct glyph_matrix *matrix) } } +/* Whether to remember a few of the last marked values for debugging. */ +#define GC_REMEMBER_LAST_MARKED 0 + +#if GC_REMEMBER_LAST_MARKED enum { LAST_MARKED_SIZE = 1 << 9 }; /* Must be a power of 2. */ Lisp_Object last_marked[LAST_MARKED_SIZE] EXTERNALLY_VISIBLE; static int last_marked_index; +#endif +/* Whether to enable the mark_object_loop_halt debugging feature. */ +#define GC_CDR_COUNT 0 + +#if GC_CDR_COUNT /* For debugging--call abort when we cdr down this many links of a list, in mark_object. In debugging, the call to abort will hit a breakpoint. Normally this is zero and the check never goes off. */ ptrdiff_t mark_object_loop_halt EXTERNALLY_VISIBLE; +#endif static void mark_vectorlike (union vectorlike_header *header) @@ -6457,19 +6473,6 @@ mark_char_table (struct Lisp_Vector *ptr, enum pvec_type pvectype) } } -NO_INLINE /* To reduce stack depth in mark_object. */ -static Lisp_Object -mark_compiled (struct Lisp_Vector *ptr) -{ - int i, size = ptr->header.size & PSEUDOVECTOR_SIZE_MASK; - - set_vector_marked (ptr); - for (i = 0; i < size; i++) - if (i != COMPILED_CONSTANTS) - mark_object (ptr->contents[i]); - return size > COMPILED_CONSTANTS ? ptr->contents[COMPILED_CONSTANTS] : Qnil; -} - /* Mark the chain of overlays starting at PTR. */ static void @@ -6622,63 +6625,115 @@ mark_window (struct Lisp_Vector *ptr) (w, mark_discard_killed_buffers (w->next_buffers)); } -static void -mark_hash_table (struct Lisp_Vector *ptr) -{ - struct Lisp_Hash_Table *h = (struct Lisp_Hash_Table *) ptr; - - mark_vectorlike (&h->header); - mark_object (h->test.name); - mark_object (h->test.user_hash_function); - mark_object (h->test.user_cmp_function); - /* If hash table is not weak, mark all keys and values. For weak - tables, mark only the vector and not its contents --- that's what - makes it weak. */ - if (NILP (h->weak)) - mark_object (h->key_and_value); - else +/* Entry of the mark stack. */ +struct mark_entry +{ + ptrdiff_t n; /* number of values, or 0 if a single value */ + union { + Lisp_Object value; /* when n = 0 */ + Lisp_Object *values; /* when n > 0 */ + } u; +}; + +/* This stack is used during marking for traversing data structures without + using C recursion. */ +struct mark_stack +{ + struct mark_entry *stack; /* base of stack */ + ptrdiff_t size; /* allocated size in entries */ + ptrdiff_t sp; /* current number of entries */ +}; + +static struct mark_stack mark_stk = {NULL, 0, 0}; + +static inline bool +mark_stack_empty_p (void) +{ + return mark_stk.sp <= 0; +} + +/* Pop and return a value from the mark stack (which must be nonempty). */ +static inline Lisp_Object +mark_stack_pop (void) +{ + eassume (!mark_stack_empty_p ()); + struct mark_entry *e = &mark_stk.stack[mark_stk.sp - 1]; + if (e->n == 0) /* single value */ { - eassert (h->next_weak == NULL); - h->next_weak = weak_hash_tables; - weak_hash_tables = h; - set_vector_marked (XVECTOR (h->key_and_value)); + --mark_stk.sp; + return e->u.value; } + /* Array of values: pop them left to right, which seems to be slightly + faster than right to left. */ + e->n--; + if (e->n == 0) + --mark_stk.sp; /* last value consumed */ + return (++e->u.values)[-1]; } -void -mark_objects (Lisp_Object *obj, ptrdiff_t n) +NO_INLINE static void +grow_mark_stack (void) { - for (ptrdiff_t i = 0; i < n; i++) - mark_object (obj[i]); + struct mark_stack *ms = &mark_stk; + eassert (ms->sp == ms->size); + ptrdiff_t min_incr = ms->sp == 0 ? 8192 : 1; + ptrdiff_t oldsize = ms->size; + ms->stack = xpalloc (ms->stack, &ms->size, min_incr, -1, sizeof *ms->stack); + eassert (ms->sp < ms->size); } -/* Determine type of generic Lisp_Object and mark it accordingly. +/* Push VALUE onto the mark stack. */ +static inline void +mark_stack_push_value (Lisp_Object value) +{ + if (mark_stk.sp >= mark_stk.size) + grow_mark_stack (); + mark_stk.stack[mark_stk.sp++] = (struct mark_entry){.n = 0, .u.value = value}; +} - This function implements a straightforward depth-first marking - algorithm and so the recursion depth may be very high (a few - tens of thousands is not uncommon). To minimize stack usage, - a few cold paths are moved out to NO_INLINE functions above. - In general, inlining them doesn't help you to gain more speed. */ +/* Push the N values at VALUES onto the mark stack. */ +static inline void +mark_stack_push_values (Lisp_Object *values, ptrdiff_t n) +{ + eassume (n >= 0); + if (n == 0) + return; + if (mark_stk.sp >= mark_stk.size) + grow_mark_stack (); + mark_stk.stack[mark_stk.sp++] = (struct mark_entry){.n = n, + .u.values = values}; +} -void -mark_object (Lisp_Object arg) +/* Traverse and mark objects on the mark stack above BASE_SP. + + Traversal is depth-first using the mark stack for most common + object types. Recursion is used for other types, in the hope that + they are rare enough that C stack usage is kept low. */ +static void +process_mark_stack (ptrdiff_t base_sp) { - register Lisp_Object obj; - void *po; #if GC_CHECK_MARKED_OBJECTS struct mem_node *m = NULL; #endif +#if GC_CDR_COUNT ptrdiff_t cdr_count = 0; +#endif - obj = arg; - loop: + eassume (mark_stk.sp >= base_sp && base_sp >= 0); - po = XPNTR (obj); + while (mark_stk.sp > base_sp) + { + // FIXME: reindent loop body + Lisp_Object obj = mark_stack_pop (); + mark_obj: ; + void *po = XPNTR (obj); if (PURE_P (po)) - return; + continue; +#if GC_REMEMBER_LAST_MARKED last_marked[last_marked_index++] = obj; last_marked_index &= LAST_MARKED_SIZE - 1; +#endif /* Perform some sanity checks on the objects marked here. Abort if we encounter an object we know is bogus. This increases GC time @@ -6781,16 +6836,6 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0) mark_buffer ((struct buffer *) ptr); break; - case PVEC_COMPILED: - /* Although we could treat this just like a vector, mark_compiled - returns the COMPILED_CONSTANTS element, which is marked at the - next iteration of goto-loop here. This is done to avoid a few - recursive calls to mark_object. */ - obj = mark_compiled (ptr); - if (!NILP (obj)) - goto loop; - break; - case PVEC_FRAME: mark_frame (ptr); break; @@ -6800,8 +6845,27 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0) break; case PVEC_HASH_TABLE: - mark_hash_table (ptr); - break; + { + struct Lisp_Hash_Table *h = (struct Lisp_Hash_Table *)ptr; + ptrdiff_t size = ptr->header.size & PSEUDOVECTOR_SIZE_MASK; + set_vector_marked (ptr); + mark_stack_push_values (ptr->contents, size); + mark_stack_push_value (h->test.name); + mark_stack_push_value (h->test.user_hash_function); + mark_stack_push_value (h->test.user_cmp_function); + if (NILP (h->weak)) + mark_stack_push_value (h->key_and_value); + else + { + /* For weak tables, mark only the vector and not its + contents --- that's what makes it weak. */ + eassert (h->next_weak == NULL); + h->next_weak = weak_hash_tables; + weak_hash_tables = h; + set_vector_marked (XVECTOR (h->key_and_value)); + } + break; + } case PVEC_CHAR_TABLE: case PVEC_SUB_CHAR_TABLE: @@ -6828,11 +6892,11 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0) { set_vector_marked (ptr); struct Lisp_Subr *subr = XSUBR (obj); - mark_object (subr->native_intspec); - mark_object (subr->command_modes); - mark_object (subr->native_comp_u); - mark_object (subr->lambda_list); - mark_object (subr->type); + mark_stack_push_value (subr->native_intspec); + mark_stack_push_value (subr->command_modes); + mark_stack_push_value (subr->native_comp_u); + mark_stack_push_value (subr->lambda_list); + mark_stack_push_value (subr->type); } #endif break; @@ -6841,9 +6905,16 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0) emacs_abort (); default: - /* A regular vector, or a pseudovector needing no special - treatment. */ - mark_vectorlike (&ptr->header); + { + /* A regular vector or pseudovector needing no special + treatment. */ + ptrdiff_t size = ptr->header.size; + if (size & PSEUDOVECTOR_FLAG) + size &= PSEUDOVECTOR_SIZE_MASK; + set_vector_marked (ptr); + mark_stack_push_values (ptr->contents, size); + } + break; } } break; @@ -6858,16 +6929,16 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0) set_symbol_marked (ptr); /* Attempt to catch bogus objects. */ eassert (valid_lisp_object_p (ptr->u.s.function)); - mark_object (ptr->u.s.function); - mark_object (ptr->u.s.plist); + mark_stack_push_value (ptr->u.s.function); + mark_stack_push_value (ptr->u.s.plist); switch (ptr->u.s.redirect) { - case SYMBOL_PLAINVAL: mark_object (SYMBOL_VAL (ptr)); break; + case SYMBOL_PLAINVAL: mark_stack_push_value (SYMBOL_VAL (ptr)); break; case SYMBOL_VARALIAS: { Lisp_Object tem; XSETSYMBOL (tem, SYMBOL_ALIAS (ptr)); - mark_object (tem); + mark_stack_push_value (tem); break; } case SYMBOL_LOCALIZED: @@ -6898,19 +6969,20 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0) break; CHECK_ALLOCATED_AND_LIVE (live_cons_p, MEM_TYPE_CONS); set_cons_marked (ptr); - /* If the cdr is nil, avoid recursion for the car. */ - if (NILP (ptr->u.s.u.cdr)) + /* Avoid growing the stack if the cdr is nil. + In any case, make sure the car is expanded first. */ + if (!NILP (ptr->u.s.u.cdr)) { - obj = ptr->u.s.car; - cdr_count = 0; - goto loop; + mark_stack_push_value (ptr->u.s.u.cdr); +#if GC_CDR_COUNT + cdr_count++; + if (cdr_count == mark_object_loop_halt) + emacs_abort (); +#endif } - mark_object (ptr->u.s.car); - obj = ptr->u.s.u.cdr; - cdr_count++; - if (cdr_count == mark_object_loop_halt) - emacs_abort (); - goto loop; + /* Speedup hack for the common case (successive list elements). */ + obj = ptr->u.s.car; + goto mark_obj; } case Lisp_Float: @@ -6930,11 +7002,29 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL() ((void) 0) emacs_abort (); } + } + #undef CHECK_LIVE #undef CHECK_ALLOCATED #undef CHECK_ALLOCATED_AND_LIVE } +void +mark_object (Lisp_Object obj) +{ + ptrdiff_t sp = mark_stk.sp; + mark_stack_push_value (obj); + process_mark_stack (sp); +} + +void +mark_objects (Lisp_Object *objs, ptrdiff_t n) +{ + ptrdiff_t sp = mark_stk.sp; + mark_stack_push_values (objs, n); + process_mark_stack (sp); +} + /* Mark the Lisp pointers in the terminal objects. Called by Fgarbage_collect. */ -- 2.32.0 (Apple Git-132) --Apple-Mail=_3A69BF77-D790-4292-9ACE-B285B48060C6-- ------------=_1649092742-25011-1-- From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Apr 2022 01:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Lars Ingebrigtsen , 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164912132913990 (code B ref 54698); Tue, 05 Apr 2022 01:16:01 +0000 Received: (at 54698) by debbugs.gnu.org; 5 Apr 2022 01:15:29 +0000 Received: from localhost ([127.0.0.1]:53411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbXn7-0003da-Gl for submit@debbugs.gnu.org; Mon, 04 Apr 2022 21:15:29 -0400 Received: from sonic308-10.consmr.mail.ne1.yahoo.com ([66.163.187.33]:45642) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbXn5-0003dE-BZ for 54698@debbugs.gnu.org; Mon, 04 Apr 2022 21:15:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649121321; bh=MwnyjKmJOGWhtslaDDY+q2SmPGL6HIAcgSuuu4dJNqo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=PmcMzhQrTmdaJ0qFfgiXhzEesbHq3DQXhHiUsnLhq0hsrqzr9wUq3Jyc4K5GNoBOPz3P+YYS9vtjUSDTqg1u4EiqAyb+LOjIZmormMFwszakXe42MiWROLJeEEAwjI3uvt21nRKOI/Ezegu5Ux/ypEoZTv1oO20Z4xEAr5yzE6waj0A+iV5eCcUX2U3EEYwHDpN/3z1gKu6jyAMTaGB5iRgZuEE28cknQoQBr4H1cYWNSoP4tlIqd3o10j9E/JL3Xgau0uRzvlJr6NIY65ZuFCjoFIXyW5Knf+5y6FKMqwzkyWHqpnIp6ummotcYx/OuNSfhuoDBNzjR6WrsBX5a6Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649121321; bh=Ji0I2DtmI/HRD2nuVcoOeZi6Mg6f0c/sItzubnrNZGv=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=Z4dKOSoqLwzW0Gj7R2mXa0Kppwb9EciTYzHLxEp4BFc/E526Law/zMWg8A0+RfV1r8cS/Y5MvuBQhEPm4eG5hF9xbPEIlAIMKGmg9cydpF6srmQ6LAPVl8+n+SVJbU/VoCbu9vXW3z9M3wRc2BqFkUTAH4K37I5eTKkz1Hd+sqFMn0v1LijkFKXwAZweSFDkasluGAWnsWLU0pjOb2KDMmM9uBqIakVPulQtI+BMMKyqw4Uew2mknNYiGR4uPakwNsUdX4YUO08AB9iAIzQbo2K+nfRXqx214C+4/HDKDeMvLD0Q1tHh1rotT6QeJjdF7AHtK/dJT9cFkXWofoTvtQ== X-YMail-OSG: vpPcRR0VM1njQdrQHMwzEB1ilzo4uwD1ajpu.xjPiwwBBPaa93HQC_uCgKECDPF varq7CW7QCM_Sqe_cIuCneywrgncG4MJpeOjUFn7btps1e64uIIXje73tfMqSo7rx9.OY68BPFMY LXGXyfd0okZjA7nRiwhn2ZihO11pGHZD8StNpGjGO8VS2VyQGV6TFMZRNNp5OxDrX.YH33D1oVy2 eIp314Clbd0Q71wrzHML5Mtg8IClmldvMiU2ZOBwmkdYPi87jvmWP4BCi.QlHFehlLv7AOuz67x_ yHQNSg7lL4.xEiR_CjTZxhUDYLAi9kVr0GQfSwPAkD2pCY9lg8_GUA2OxTUFkDeYqZFEbk8hyET6 1rUvpXgA0VFQaOqtadlGQX3Osfe4JAbCG_yrD967j_kavCcqTbsDlCZ6_LjiQ4ucgLA2X_RA9yLr .kJNuJY18ZnkOUg7M.61IAnED9fhp6O_Yysow.phIGxKr.tRhEQoFWMWP6QpgdjWR_iypOccXKGK F1.i1UcAYN14ilY1bs3RMDgfM89lOzj05F4WONH6tABQu3i4aNZsaxkg6fzPxJ2bfKIE3SBJs21C rWRiFRHv4Te43k2fUtSvrrHOok5wjtQRAeE_LTirC5yTyEBLcGE9YlNHoapHnooVebAvQg7Id.a8 Olo2LLpa8ffo5AZHihBXX41Mbxlfe0YbqLTZE.4D5ZikFV5hXLSnEIjx8gXuFmyZmBqlL4Lcq4vK doTvI1I3NsghAN98s0a0yhu58YvgGHx1NpGogxYBdVBK.5gsdBMNfIlSS7ZwwfC5bKRciX7ukM28 YCJqa4lbIGn6JepJHxtDfZEmRp0loB3ocsEM9OXNUmlB9PrOEGCfvQH_gBtY6nyq1avHYUJ8Q6rI JqhlhEjCr5Rp2bqbo.mYEGZ9bEStKrh7QEWFWobS6tLGmKuLnjSTQ0jKFIjczC3EFrYZETcsLq11 VoCk1DKPxndRYaTb9ccm0epDvrnImouEOM7OZUm_4id6xOiahlLjlU.BsUaqopnFWdHSSTf3My_x wQ1aCsUio24m5ehbKBGC26Pvm7M4akBVzwASvwKz3_uBjlIdcIuvmim0_NQCRyDlEu7t4Pj0QuHC RIt7.1R129qDpmilCOmDpF6s_ONEDZw7ztiM8p4nJRPhoUozHZYjkSAqj.jvt6xdIKwVSvP6lZwt iQ3pMamj6uBVUdR5br8h_FSNyOqM9qzkmmmO_UF3ebAlRBc1MJXSeBxUOI5oxre1g756A4kCzfpG _rmDN090xkx0.6Sxip662bZVZ6wjBFA1YPUILJi8ravbEL4baELiPNi7JvMWxyrJdgQ6GSBYQyLc 3O_IkuerWeU4.nBMeqsPgKPfHP9lzY4q24oa9XmEj3O_h7s1jI2zA97.VFdwll_UQcpcjvxx3oeT w0WtJ89PJUehgqgkH5LeV1AhT6uFZ456iBhNOtB26GrBTddbjZMpC_0FskIq5V8ORi6HVa8OJ9hq b.H1Lexz6JjVqNuPSuMJwHLxa1..AJ06ZeuIdG5pZtQPVxdlv0AF_s3ovh3DSUM2q4CSc1q9UCGv Xk.AIz5eErekM__gVwIaTRelWMY0wr.ita4vNybl_Pt6F8cCos0WmLu0Hopn8Vs3Ky_9HQlpJ.Hq nDB8_he.lSr6RExyd1vxVi5sJ_TfbxjCqN31umZk45IjjBbvfbH5PHgivxVRxFMdwWmDdeaV7H_L woOwxZr6tqKfqkRyjVeBtCUBsFKMlBT3q4dxE7MRGlosaKzJydrTqJ8eupNCuKVf5Sf77Rv9hyUi eICTsgldn6tx.ADmk0OEfQeDPx_kb9kkIlrfnLczD.Uqf44OY1asJnAX6.IsWV62qj7iNryGrpeq e51usOFPF97D27QT0R0TotPLDE4xV12EPisbwl2W1idIrt808tQwjalDVC16gzomX61A_P6_pMfm jF.JQfXnK4tNUolb3kS1S67U4tY7kj6f3vHHpfbZW4.Zp082DXpyfpqQ1VwOCgk.El6fCKB1n_ph 0j7c2AR.xo9QLO9csR97hweAe8SX6bELf3uqwLptgZ7vDHEe2eDbBRZuvIK5D8CXkDalIJR1Ul7E 0wBodVeUgUsEIagAAKG7ADm4G.suJLhnGX9VDir4wfR8bCdqQMKM9_Wb.9fE2o8O3yvyZ5LFAUcJ erboc_9paZcGFxZ5z5ChPq5q3orctIqp0_xPj1gaAdz8yypJ0YAbCtJR7NwdJZwWbH7cr4aklKH0 Pllnf5ja4NMZH3qd1qL8gL2RE96bMwcTsuqnj5AHEd9iyzoebCHskmjU5iVdgSds5Q8c- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Tue, 5 Apr 2022 01:15:21 +0000 Received: by hermes--canary-production-sg3-65d7bd97b5-gqv44 (VZM Hermes SMTP Server) with ESMTPA ID 8380ecf653bf650f4c798acb9b159d39; Tue, 05 Apr 2022 01:15:15 +0000 (UTC) From: Po Lu References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> Date: Tue, 05 Apr 2022 09:15:09 +0800 In-Reply-To: <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Mon, 4 Apr 2022 13:16:26 +0200") Message-ID: <871qyc5o0y.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.20001 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 758 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 (-) Mattias Engdeg=C3=A5rd writes: > No, the mark stack grows as needed. I see no reason to limit the size > since it's going to be much smaller than the size of the heap being > traced in any case. What happens if it runs out of memory? The incremental GC I'm working on also has a similar stack for objects that have not been marked yet, and it also grows dynamically. If growing the stack fails, it aborts garbage collection and tells the user to type C-x s and exit Emacs. Objects are left with mark bits, but that is the case when Lisp code is allowed to run "between" parts of garbage collection anyway, and I hopefully did a good enough job fixing the code that assumed objects cannot have mark bits during regular Lisp execution. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Apr 2022 08:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Po Lu Cc: Lars Ingebrigtsen , 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.16491461045366 (code B ref 54698); Tue, 05 Apr 2022 08:09:01 +0000 Received: (at 54698) by debbugs.gnu.org; 5 Apr 2022 08:08:24 +0000 Received: from localhost ([127.0.0.1]:53692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbeEi-0001OU-HA for submit@debbugs.gnu.org; Tue, 05 Apr 2022 04:08:24 -0400 Received: from mail1442c50.megamailservers.eu ([91.136.14.42]:41902 helo=mail264c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbeEf-0001OB-DZ for 54698@debbugs.gnu.org; Tue, 05 Apr 2022 04:08:22 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1649146094; bh=acQh9L/ASz/AnMu27UxWYDpXhUahfsF0XrBalm5qHnU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=XyDzzLQiB9lcqfuSHxiT81Ii/MkqFORZjn3BHCuV8RJ8yVQ1W4FGYogOB3CKj8fGc J21F62ttVltPybdtjOBDpW5ukSQjyG54d2I6vumtZnNSNZ4dPu8+YMD6cBMHG5NX65 SHSepVDI5Y/n/kT0UwjjYC3LNmIMzu+4KqyMU5jw= Feedback-ID: mattiase@acm.or Received: from smtpclient.apple (c-b952e353.032-75-73746f71.bbcust.telenor.se [83.227.82.185]) (authenticated bits=0) by mail264c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 23588CCG006831; Tue, 5 Apr 2022 08:08:13 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= In-Reply-To: <871qyc5o0y.fsf@yahoo.com> Date: Tue, 5 Apr 2022 10:08:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-CTCH-RefID: str=0001.0A742F17.624BF8EE.003C, 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-Origin-Country: SE X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 5 apr. 2022 kl. 03.15 skrev Po Lu : > What happens if it runs out of memory? Good question! In theory the answer is simple: abort, as with any other failed xmalloc. Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.0 T_SCC_BODY_TEXT_LINE No description available. 0.3 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS 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 (/) 5 apr. 2022 kl. 03.15 skrev Po Lu : > What happens if it runs out of memory? Good question! In theory the answer is simple: abort, as with any other = failed xmalloc. In practice, though, malloc probably won't fail at all -- more likely = the OS will keep handing out addresses from its 64-bit space and slowly = swap itself to death. On Linux, the out-of-memory killer will murder = some essential processes at some point. If you have a hard disk you will = at least get a premonition of what is going to happen from the rumbling. But it would take a lot of heap for the mark stack requirements to = become that big; it's much more likely that you run out of memory = allocating your Lisp objects (or something else) first. > The incremental GC I'm working on also has a similar stack for objects > that have not been marked yet, and it also grows dynamically. That's nice! I'm using a monolithic stack because it's easiest and gives = good performance. A segmented stack would be an alternative for extreme = memory conditions but the extra segment underflow checks would make the = common case slower. (I have a patch for using a segmented stack in the = bytecode engine, where it makes more sense and the overhead is lower, = but it's still nonzero.) > If growing the stack fails, it aborts garbage collection and tells the > user to type C-x s and exit Emacs. Frankly I wouldn't trust saving buffers to be possible when growing the = mark stack wasn't. Have you actually tested this? > Objects are left with mark bits, but > that is the case when Lisp code is allowed to run "between" parts of > garbage collection anyway, and I hopefully did a good enough job = fixing > the code that assumed objects cannot have mark bits during regular = Lisp > execution. That requires some careful invariant maintenance but I could see it = working. Is the collector generational as well? Otherwise I suppose the = total GC cost is higher than before, right? From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Apr 2022 08:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Lars Ingebrigtsen , 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.16491479898774 (code B ref 54698); Tue, 05 Apr 2022 08:40:02 +0000 Received: (at 54698) by debbugs.gnu.org; 5 Apr 2022 08:39:49 +0000 Received: from localhost ([127.0.0.1]:53713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbej6-0002HS-LI for submit@debbugs.gnu.org; Tue, 05 Apr 2022 04:39:48 -0400 Received: from sonic307-56.consmr.mail.ne1.yahoo.com ([66.163.190.31]:34735) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbej3-0002H3-Lx for 54698@debbugs.gnu.org; Tue, 05 Apr 2022 04:39:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649147979; bh=zBD30jFJxUna6FIDejZyl9ZZwYnboa6wr4oacuS6Pgc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=LASEX7MneHYnDXYRe5MKfX3XoBkYn6jaRmycEk5pnwpFwfjPodeccqCarYFnndwikacqe/L5niAVJ+wN8w0zWP8FbjmT4BTPeeEupXFPxFuzVZZvLpg0t+IIgWJPprD8agtZRe4AZqjUq00euOPI43E6F81rwr7WGEnwfcrFv3+WE/GCm+sE19uiJJMrzAIyS2ZJfAMTEeCVHsIeqK/y6Bk4dPEajtSegjBvmCWlrvLnbanKjZqPI+PoXVNtiVu7Gsp/OESJJFVECzmkNo14hCIVJtp2VRL0Q2dn8bsxlzKbrJvjw7qjL86ES5zeVAhCIdsYNbihJRZ1qk3GlXxW4g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649147979; bh=1LONKQDat3ILzXP900DX0vZBaUDgB+t9WHBMx9XbCSn=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=SguIHHfJB+hDHbU3RQTAdRFNAEW0FGyHC4X1IJz5ehsex/hdNTsHiirZiz+G1nx92mtWOlaesVgPccBka4BAlX9NEOXCMF7TkhHE8T6Xud1CcS+Ff5YgWrT+3oil6RYH4kvJsZDR+iAawGgmspnK6A3NXfLOPrM4CKd+rvDq2rRUMY/8HOphho0UDbHBy9ybubF2gApLXcIxT4ZeAUwOd/UqvuXJjdSDBfweBQfI4NWVZ1/G7YKjjb0LVgttN7mXE1ePZXMVKFH3lpgU6lLA6daiZdbkFqOICnLcb15f5tmxZ+hCZwKjCQ0RirbcZbouzUJpgx/t27TMY4m447b1Nw== X-YMail-OSG: KdBTAsoVM1mWResMX1AEv8wRDRyApcdBdka9_7CRJy1BP.dI326ZBVk8PMD6N8Q EwuuLRT88vcVsGc4ZesCw.xJ_Exm0Tdq.bP6jXNKYlS46sN9RTObM7FDOwpv3OX4m5ar02ljofvb X3aINErw1EUJhok1UcP5lFlmrVbdSlpMEzFabhyKs_G.bSCRM526KQw48GJKtXH5zSxVuFBM5s3u Wh.gualP2BLTlM2BmMZHDTaIFNdxtxULGKNmoZ7j2Gwh_yZZm_8cp.B6BphmjJkplcdSCVVx0x5o CAk5hxVuiZ8IKWyF._uGrJsBDWtff6GrLGG7qZPb18i6YRDODg9KUAW7zTMef2mq18AbnPtd_mb8 RVnoZ.WowiNw_zNGkzs27arws5pMiVHHeGX3SwFylJ4i2litgs99DqEQeZkeeDqy5xto9kOXtN3C lnD_QHvzGckmXVMjxGWVDmPHyYwtiFiyDj0TeiV1NZUZeDa3moAR8_8LIBRF7aKA_qn6zge3Mz0d y7rx421pm.hk0b0CrTvtaiZPbB1OFrpavo7SHC.6x2Of_cc1P4vIahBEKkrceyWTe3a9RGdMAoyK 9.lsOLywqYUgPDYRtLVH42lx5hscRlSjALYUIhhubHjJhLq4woPWyKeSu88oRWrxoMHQvB04I9nx yD5yuk10N.cYMprjHMKcU4pYRMLF6dWZy9zzUEKx3o6fOKuPDI0prL1BZH8xg3HiEHNOsOPOf9AQ YrGTXsYc7tzqg_90ETcIEuhoE0ytyn_J9KkhyiOXWVv5.Tmp8kCgY.oeYifVVUYBamjkdw76RIZ9 nRaJX2DDhSnuNmF0Dy95KeWRo7LH_DvoxUcdIKqiOT7s8TkgSrOnrcKVP.LyZDhjawt068yUsywj QgOy2oU75aJPumdwCJB5qVdSjwiXUu78RCLJZnnsHl1ctV0gZZ5I7UeEytmM.oLzVHuV2DysY8QY QiDrvrIPlPmNlGArNBhyjOJe7WMNEhLAbiKJkVRoqWJyCqRa3Tim1sxxCJlEQxS6MVlpRO7nLtS7 qIoAKK_kGecRd6SHOVTXVScbH5l6EczfezJpLL_ZCfBWl3d27Nt8poRDI87RDNc4Wi5WQnTUaSG4 KNjDfbZRKlFaOTZAqWLtpPpI4vLcd0Jg1iI65tvRg3oh.ChjKI54Dqg6qtBhEPBIP2zvoVVljbFP 7DCziwbzo500EJ40pBjN5cpX2YgxVCssaI2EryM0UwfxOhV7xcM68OwsMCHN6tSua9bVGP6tt3He g2OpX2fwguV4h2eCbhEhpwHqWsos6.Gdvo6Pf2Dv_Uldg3f7pgvT93aqx0v_h1YLj_MIUYRl34By 7mYjh0BsByCckTqjgy6SvQt8mk0Uybdn_fa21Osg_waUp_LQpI._7t8hhZLPxTeP62ivbi.jZUWw InWcM8U5zCaOQfjB1zAJ9YSeKJNC4FjWrF.xmeU9lOpiZI_r1Sx..nYY_t7F8zAuy1el40n25qUq j_M2wtgjT13LTAuSKkl5HPicf3.PbskAqFmV5VJaJe2jN_F.9Y0eQMVw712lKXlTh8fpy8toI9Mk qF1Cr7zxAA3hUp.HUjw3h4EQ9nwRVIz7lDEIDXlF.8pbdCERXj_l4Tyx.MTQC0Qz4X1KORIrr_l2 txB76sVASavBWoxrwORNzC23H3xtxnx0qm.9hMLoKD2n1ItZMPYOKZtenjDnRGSRmUlkPejcmNgH RoY.LDY2TM1LPbpEqY_pmebEcXMebGb_j.vZfV.V5pM0KzIL_rEGAvmbCz8nJlZk76RuTu9M_1mp 082dxLKAO1PBgcNa.kctY24cp_hdRq6ZkyiLE.Ztq7yRMg2ImAuiiQ.Mfd8mefZfHp6ny10Eh.Fc tXzZpHIAiJ8_ktW5UUt8gijFJCwVPsP_cykUFBsJxip_Kn_p2u1Jd4bd1ZQaofe3x3cwVqlf4Nxr _xwrrj8idxEAhavM7V1PKngLmknRj3M0IhDFTGNWmmwRhS.ueqVWZsPpMckWgASthw_pStIjI7Yh bTa7y3jld_hniboUiZ8fvdeLm8jFOu2o7LBs6bQeYZJnC7Qg2_HeBk.6uVq3ulplRhYh4Fzpozuj AD3HC6Gt11JkRRBGMBIIUfxmcQ0d6zSAAS0AqHH_89EkmmpCJTVEzFdPokK08P8DZeW4bJJCpl7D bFHNyQtT2RLL1LhLgqhcBvVs.M3DdcOrFz_HvimLYWfx1OCWYl2WrYAbqlDFwGu1LXFSWvEjuCfO CQC2ccDzfU55GbxPBKAsindfn78o5TrI8iNpz0H_7rIjR0aGOl7m.2KfbyPRq8oeLmNHi X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Tue, 5 Apr 2022 08:39:39 +0000 Received: by hermes--canary-production-sg3-65d7bd97b5-rvrjv (VZM Hermes SMTP Server) with ESMTPA ID 1537f27f31782e718df816676eafe5b4; Tue, 05 Apr 2022 08:39:34 +0000 (UTC) From: Po Lu In-Reply-To: <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Tue, 5 Apr 2022 10:08:11 +0200") References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Date: Tue, 05 Apr 2022 16:39:30 +0800 Message-ID: <87czhv53gd.fsf@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.20001 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 2771 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 (-) Mattias Engdeg=C3=A5rd writes: > Good question! In theory the answer is simple: abort, as with any > other failed xmalloc. I think a failed xmalloc will also make Emacs prompt to "C-x s, then exit". But the regular memory_full codepath might not work during garbage collection. (Mark bits get left around, for example). > In practice, though, malloc probably won't fail at all -- more likely > the OS will keep handing out addresses from its 64-bit space and > slowly swap itself to death. On Linux, the out-of-memory killer will > murder some essential processes at some point. If you have a hard disk > you will at least get a premonition of what is going to happen from > the rumbling. > > But it would take a lot of heap for the mark stack requirements to > become that big; it's much more likely that you run out of memory > allocating your Lisp objects (or something else) first. Indeed. > That's nice! I'm using a monolithic stack because it's easiest and > gives good performance. A segmented stack would be an alternative for > extreme memory conditions but the extra segment underflow checks would > make the common case slower. (I have a patch for using a segmented > stack in the bytecode engine, where it makes more sense and the > overhead is lower, but it's still nonzero.) I agree. > Frankly I wouldn't trust saving buffers to be possible when growing > the mark stack wasn't. Have you actually tested this? That code wasn't tested in an actual out-of-memory situation yet (it's too soon to consider this), but hopefully it will work. I think it works when running out of memory in general, because otherwise it wouldn't be what memory_full eventually asks the user to do. Emacs keeps a small amount of malloc'd "spare memory" around during normal execution, and frees it when running out of memory, so that some allocation might be able to continue. I didn't yet touch that mechanism, but it should perhaps be replaced by a mechanism that directly allocates objects out of that spare memory. > That requires some careful invariant maintenance but I could see it > working. Is the collector generational as well? It isn't. > Otherwise I suppose the total GC cost is higher than before, right? Yes, the total GC cost is higher than before. Lisp execution during the garbage collection is also much slower than otherwise, since (for starters) a linear search through the page aligned "block" of objects is used every time a hardware write barrier is hit. There's a lot of other low hanging fruit for optimization as well, but it's too early to work on those, since at present the garbage collector is not even working due to the recent changes that added a manually managed stack to the bytecode interpreter. Thanks. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Apr 2022 09:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164914986312422 (code B ref 54698); Tue, 05 Apr 2022 09:12:01 +0000 Received: (at 54698) by debbugs.gnu.org; 5 Apr 2022 09:11:03 +0000 Received: from localhost ([127.0.0.1]:53750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbfDL-0003EI-6t for submit@debbugs.gnu.org; Tue, 05 Apr 2022 05:11:03 -0400 Received: from mx.sdf.org ([205.166.94.24]:54969) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbfDJ-0003Dk-MK for 54698@debbugs.gnu.org; Tue, 05 Apr 2022 05:11:02 -0400 Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 2359AtMg022792 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 5 Apr 2022 09:10:55 GMT From: Andrea Corallo References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <9E8C13E8-3803-4F1C-8EA0-029D71A8C291@acm.org> Date: Tue, 05 Apr 2022 09:10:55 +0000 In-Reply-To: <9E8C13E8-3803-4F1C-8EA0-029D71A8C291@acm.org> ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Mon, 4 Apr 2022 18:04:55 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (-) Mattias Engdeg=C3=A5rd writes: > 4 apr. 2022 kl. 17.44 skrev Andrea Corallo : > >> We have some benchmarks in elisp-benchmarks that is GC bounded (IIRC >> nbody at least), I guess would be worth running. > > Go for it! I'm sorry I've really no time these days to test it myself. But I think should be up to the proponent of such a deep (and nice) change to provide a bare number of measures to convince the community that there's no negative performance inpact in order to have the patch accepted. Best Regards Andrea From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Apr 2022 11:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Po Lu Cc: Lars Ingebrigtsen , 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164915711226710 (code B ref 54698); Tue, 05 Apr 2022 11:12:02 +0000 Received: (at 54698) by debbugs.gnu.org; 5 Apr 2022 11:11:52 +0000 Received: from localhost ([127.0.0.1]:53849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbh6F-0006wj-Px for submit@debbugs.gnu.org; Tue, 05 Apr 2022 07:11:52 -0400 Received: from mail153c50.megamailservers.eu ([91.136.10.163]:35474 helo=mail50c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbh6D-0006wa-Cg for 54698@debbugs.gnu.org; Tue, 05 Apr 2022 07:11:50 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1649157107; bh=rV7MNZaozTh/fIkWgnEHFHEXHMCFXErKRewpFdNVRuo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=EcKbu3AyeWLebvpIsgDY9CyTFBsyUDeCtyG4L8Z7M6Q7NuiVgyp2rrmlHYYELf23v VNnZJvGTcqpsg0D0o1KZflIaFtOVDo3cDX3zHgDZO1l7z8H58sPZuNyxNqA1glnWXA vJKiefmIg9pL6PP6j2gSfc8aygZijWDMToIKByww= Feedback-ID: mattiase@acm.or Received: from smtpclient.apple (c-b952e353.032-75-73746f71.bbcust.telenor.se [83.227.82.185]) (authenticated bits=0) by mail50c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 235BBjMV002596; Tue, 5 Apr 2022 11:11:46 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= In-Reply-To: <87czhv53gd.fsf@yahoo.com> Date: Tue, 5 Apr 2022 13:11:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <75F6D65B-9CA1-4ECF-97BD-B934A84EB2CA@acm.org> References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <87czhv53gd.fsf@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-CTCH-RefID: str=0001.0A742F19.624C23F3.003D, 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-Origin-Country: SE X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 5 apr. 2022 kl. 10.39 skrev Po Lu : > I think a failed xmalloc will also make Emacs prompt to "C-x s, then > exit". Yes, you're probably right. (Never seen it happen myself.) Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.0 T_SCC_BODY_TEXT_LINE No description available. 0.3 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS 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 (/) 5 apr. 2022 kl. 10.39 skrev Po Lu : > I think a failed xmalloc will also make Emacs prompt to "C-x s, then > exit". Yes, you're probably right. (Never seen it happen myself.) > That code wasn't tested in an actual out-of-memory situation yet (it's > too soon to consider this), but hopefully it will work. I think it > works when running out of memory in general, because otherwise it > wouldn't be what memory_full eventually asks the user to do. Out-of-memory handling is difficult to do correctly and to test, = especially on modern systems. You are right to make a reasonable effort = at dealing with it but don't go overboard -- at some point effort is = better spent on limiting user data loss in other ways (robust auto-save = in particular). > There's a lot of other > low hanging fruit for optimization as well, but it's too early to work > on those, since at present the garbage collector is not even working = due > to the recent changes that added a manually managed stack to the > bytecode interpreter. Very sorry about that (but Progress stops for nobody)! In fact the new bytecode stack should provide more opportunities for = efficient GC, but let's discuss that elsewhere. > Thanks. You're welcome. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Apr 2022 11:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Lars Ingebrigtsen , 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164915799628342 (code B ref 54698); Tue, 05 Apr 2022 11:27:02 +0000 Received: (at 54698) by debbugs.gnu.org; 5 Apr 2022 11:26:36 +0000 Received: from localhost ([127.0.0.1]:53869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbhKW-0007N3-1X for submit@debbugs.gnu.org; Tue, 05 Apr 2022 07:26:36 -0400 Received: from sonic302-21.consmr.mail.ne1.yahoo.com ([66.163.186.147]:40287) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbhKT-0007Mk-Rn for 54698@debbugs.gnu.org; Tue, 05 Apr 2022 07:26:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649157987; bh=Rn/XRbRf7gF/ryoO5WSXnsgNM2QmLtORZ7cgv5064xo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=r7XFUQnjYl8K4l75p7ZMHgINtjcJoG3YbT1IBpv4ia8uAEzzIHFFJtoA32SDr9mAWeoCwvUtyOtqBgYBARefV1bRTahjQVH7z8E5QMMTtXuCJG87sK/G+YtpU6827ry1ife/gJcxJWhBCiaNOpRmK9ngNYH0mhX0K8G7Gv5JAqDhYPjPeICEdIJsftYldd6GuNNho1dvaTCZQPdppMXeT9/oxn1ziIZ+n5X8gGkwSlpvLIQ9FWhDLWPxU4nBhbhV4vujz9gRKoJ7E+xK2Sybizve70Z6HDkx+DyUADljwMmv4YOP/EOUlTbxFtb3LpEdioEZJDEyqobOu3p5Mvk53g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649157987; bh=TmEKbM5u/XQa7w59S1VlZm6aVTjEfP3xjCxmCMdJrOX=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=qvOy7K+EMsS/tl9TcVg07oFN9boiOSX8vsQruSbxxES3sNTvsE1O4ZusyisBBLDpiq28ElCpvvHnQvsx+WPNVKVPgqhGsdmVZS5eTYEDTcCIIsQ8ITfxNRCOswwt1ERVnZEdympc/JzNVOE/tr463xcsYwu6ZlZs6mGE0kibntLbxICArH8C01GA48p6T3eupJjJd8jXk77bHBdMrG8CXMyyf69pafbAmY4L7hd12cdpUrRC9tK7PPiCQImMvDBElomjPxIdZU3WbEeVC+2OSNhffHyBB4e+jjGrqfTyvRM/0fh6flKNztzBlOIIPx3Nj0OZSzkHASrAzSiqNCWWng== X-YMail-OSG: rCRhYWgVM1kRatXTHbVtl2h9PfAGYOPsPgk0Dgn2FPegJLBdcGHyoUGMZfbxTg. Z6vpa.fzrayatoPG9ngZ9dIq2mTldQ1ihgbt8LzVxm3.WqlXvGiQENgFHIyPYc7sU45B7uDFG4Ui jFitb5xxkxqjflL8iwYAGvFbZbu76XJb45ZFJfgdzXRtGVrug0rgew7vb2pZgg5udXZZyJ00HK9P 6a2pf8.C4mSXpwuVQQUwWBbLNH2R0zStNsTGEf7inphzZmeabm_WpUTdTPqNh9e6uRvdS9Jj5Ryl 9tQVOsX8DNISA.gqsTp_pHX34YT9gipMTPVtD_TTHnAG9OiBcd06h9xyJFN4wXuY_lwN0cV17GF9 LBel7b9omzC0QX6Mmo_V4OvxzVwNmd9rvkBNcJqI1U188dDeCyDr5ImDfvV0NzIeh.MXx3YLwmiV B3SC5g3RhuoxZrl8BDSsvkef.gtLHAdRpiJr3x_yZOh5yw03x3m9CdzmOhwlY0BBbxt20QL49TJe xVjuV6M3_I5G_IYMGJPYpQWuNxmyFwQT29qKHMNsyPUjBZYyaJ4Pm69gjae7NCFG5fI44e1HNEe5 B3z6meB9_TpNoPcN1RX_VBTD8EcGaxs.1xHDW5ta082xLUcrGTk8.4F81.BFLbNpEfrqPmz23PRb Ei4OAQUxQ_LfW7l3gplcswjMGi14J5F5chtxSze.OJTOSkKaJ.OG6HJOk9zeVssirGXhWBekHWPB kuqif3zgjxSv9GIiLzXn0qk8FgnhvpVBg0co1kaialqdDqkpdgpicHgycOljqOoGzbueIjTEbGxY K3e7QBHWj.w.QNAuQSNnZUNfUtl6ITAsWlnrd8EKpMQIrRiMT2KzCeWFaQNCz8CmBMW4PeyA7.dF _iZHFXzbmcK1TlQw4odacyTHmV.MUGgVDo03jy04Yx2h3rJDWr9IYo4D379cfvCdZkbxkJcq6GKb KCsbLBT0T7gjT9CGevmxltZkyrvZVbkyDhvNSQPYzhMmb5i8pgi3tXvulYai672O7tFIlFZhuNKA lZsmSr41udGUAHW4z9ZfTpIs_dijMzyP8FMPG32J4P_3e.JfMaNKW6YRJMQErcp.ga_bWRZurSmz vK4FpPGGyp2snm.G.m_ICK_4kMmVfiyGpqGun57z0MA_Zc4yPpp94KUZwMNrjy.whstyW4AR.TUL e6OHOfgJEr0z4CW3ILBgH.bA0KI8FYd9ky.KJJl6BAGZhYOvnWnoyIHpemMh5vo728OfV2UH.By3 b9KhUV8p.exTvfF2s9eRLnfci4ABXjc8oImxJzIDFkkcGqfF6O5h_W5tsXNqMmB0aiuG8DHN6kHi bSXzFuqVbCqiW0fk7VMDZj8Hj7o0sgARdA_PWH9bvjKF5WspnCNH0tDJFNO2qD3FcmB.YIDMOUV4 uD4LP3iCm8Pcgnsld8y5.U0V3y4FQ7zdYogfNQNAtmSbv.RNh3LygBSYb28UOjqRNKIwY0jM64ZO JEu5r1HmVtnwIj7BNnrvMHXpletmd9X24..0CNfR7Cj4hfIvg4_a7lqzd3oYS2zDugq7OHR3cpD4 1sqPgFcjC8vuHsejhy4SL.4j8I0hSQljz2D3LFxZKjB8JIFXl9T3149vT7ytZqwvLlu5JkYQPLm6 6uIR3IbpuQ4s72WmQAT_aNgiv9VP04KhhncpHQJKwjACI609rxqpjllpV0o1WRpV_DYChSvaFjvA fRyJyXY2qgdVNmckHpBkbR4RxxR1RbOQ1U67fRCKo0Okn5qUzKVXSuhRgPhb5Q6m3cyws6aror._ QgdUMld0vdN1k23HO6qvNDQ0r0UuPURJUX_4A2RWr8VOXemF62ApVG2tYY_hzUAgqgkKASc39.1z wYJAkhrRhG1PaxJzd9Dhrwp8eBa2MQuMOkssKCmX1ea7f6ixnHK4JCFxNK.a_.eAiqW9v7psreHQ MKo6i4ygzxxOnKJ8Ngg_.xSdH6dChRtFdoaGL4CzS1fIke42ZYZGWe.zrLqQtJ0v5jy3Qgvybt5K g8nRNyFfD55mKdUZW1Fyr54pv7Ab48cr7znL2RUOUHY81BvRD2R7ypc.orS5wZKG5eyDLWhIEkbh ct5PQqWVMD28131mXmIeMoMkJ1TWyR3TrX6zKT..hfpR1VhVfUduj5WOVSrtU5R1Um8kJ4vASz3D kNXnIXmyJgNdbRFREdhwlAMtazQdz56_c2b0TlHfJCIDk6jF1ROUvGOphMGBpb.IIL4Y190lfjML qoRUcySTwawft82Z3X._zPeWdJW.wZFqzh309wygq6f1J.CLdV65k6cwqP9xrOKKxnZ7RMGM- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Tue, 5 Apr 2022 11:26:27 +0000 Received: by hermes--canary-production-sg3-65d7bd97b5-gqv44 (VZM Hermes SMTP Server) with ESMTPA ID 24d769b7c3b66ac931df0ebaef207335; Tue, 05 Apr 2022 11:26:22 +0000 (UTC) From: Po Lu References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <87czhv53gd.fsf@yahoo.com> <75F6D65B-9CA1-4ECF-97BD-B934A84EB2CA@acm.org> Date: Tue, 05 Apr 2022 19:26:18 +0800 In-Reply-To: <75F6D65B-9CA1-4ECF-97BD-B934A84EB2CA@acm.org> ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Tue, 5 Apr 2022 13:11:44 +0200") Message-ID: <8735ir4vqd.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.20001 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 192 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 (-) Mattias Engdeg=C3=A5rd writes: > Very sorry about that (but Progress stops for nobody)! No need to apologize, I'm responsible for the work I do in the background, thanks. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Apr 2022 11:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: luangruo@yahoo.com, larsi@gnus.org, 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.16491590016018 (code B ref 54698); Tue, 05 Apr 2022 11:44:02 +0000 Received: (at 54698) by debbugs.gnu.org; 5 Apr 2022 11:43:21 +0000 Received: from localhost ([127.0.0.1]:53879 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbhai-0001Z0-MG for submit@debbugs.gnu.org; Tue, 05 Apr 2022 07:43:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53422) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbhag-0001Yn-NJ for 54698@debbugs.gnu.org; Tue, 05 Apr 2022 07:43:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57550) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nbhaa-0005YM-HP; Tue, 05 Apr 2022 07:43:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=ujBohPcK7F+KzUkpVTc1gWpega0CyfHroKWSMYqIOXI=; b=FqxjjMA8n3oUGEIF75pN 8sUNuONSyjIPEU7aPOIzP792+UE8pRrJ3XY3KCLNHkrDF7G5y8ceEzfAE4BdvVO5p80qVOYzK1QMC yJHTXoBYSvGkToxkd+jk78yncFPYVnoZXQgSXgBriemLVYxuA63/TptyCDEy+6MMOBlXgwV2lAARi xrAYsy3siVTr5O/M8b9i2WyWghYSyIlrIP0QqRYySn7UQWW3WVW3zC6HDLko9agswA5IxuuP4sjzW AUoLhHXMHjK2kPntuP9dSZYDMxsBzwdRMswrinrvZbkhUKoZRtcTmfi2FqhxJSVgIeiwH/nGgONV3 mLKPoJD8TLnYnQ==; Received: from [87.69.77.57] (port=4606 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nbhaY-0003ju-B3; Tue, 05 Apr 2022 07:43:11 -0400 Date: Tue, 05 Apr 2022 14:43:15 +0300 Message-Id: <83fsmreox8.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Tue, 5 Apr 2022 10:08:11 +0200) References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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, 5 Apr 2022 10:08:11 +0200 > Cc: Lars Ingebrigtsen , 54698@debbugs.gnu.org > > 5 apr. 2022 kl. 03.15 skrev Po Lu : > > > What happens if it runs out of memory? > > Good question! In theory the answer is simple: abort, as with any other failed xmalloc. Emacs isn't supposed to abort when xmalloc runs out of memory. See memory_full. > In practice, though, malloc probably won't fail at all -- more likely the OS will keep handing out addresses from its 64-bit space and slowly swap itself to death. On Linux, the out-of-memory killer will murder some essential processes at some point. You mean, Emacs fails to know when it approaches the memory limit, and/or react reasonably when memory_full is called? That'd be a bug, IMO. > But it would take a lot of heap for the mark stack requirements to become that big; it's much more likely that you run out of memory allocating your Lisp objects (or something else) first. The memory allocated for the simulated stack during GC is _in_addition_ to what was used for Lisp objects. > > If growing the stack fails, it aborts garbage collection and tells the > > user to type C-x s and exit Emacs. > > Frankly I wouldn't trust saving buffers to be possible when growing the mark stack wasn't. Have you actually tested this? Emacs preserves some memory for that reason. If that doesn't work, we should fix it, IMO. Being able to save your edits when memory is full is an important safety feature in Emacs. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Apr 2022 12:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: Po Lu , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Lars Ingebrigtsen , 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164916189512030 (code B ref 54698); Tue, 05 Apr 2022 12:32:01 +0000 Received: (at 54698) by debbugs.gnu.org; 5 Apr 2022 12:31:35 +0000 Received: from localhost ([127.0.0.1]:54044 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbiLP-00037y-Dh for submit@debbugs.gnu.org; Tue, 05 Apr 2022 08:31:35 -0400 Received: from mail-oa1-f49.google.com ([209.85.160.49]:41455) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbiLO-00037i-JI for 54698@debbugs.gnu.org; Tue, 05 Apr 2022 08:31:34 -0400 Received: by mail-oa1-f49.google.com with SMTP id 586e51a60fabf-df0940c4eeso14184730fac.8 for <54698@debbugs.gnu.org>; Tue, 05 Apr 2022 05:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wzcLDAyd95h6i84x4LvRo6vEOIrvut9FdCnT+zIoJjI=; b=K7BDfLn9DujbTsm6eBjMOSHj1IQMk9buWkbGvbResItc4TOrCni3tkBIEvuMvmgpnf l+aHCaiLlg+BEdGEoCf/GQoRLSRl2GNj8Wzsuh6Z1EgLDBr9Lq16dfgKvFbTpxu7hyNi caR+vbUVhcyT2meYm+KGXaUvd4zVTAmsvwJZtxL3Egv97viu+AjHKKAN/B/eaMO/NkFg l8kxhiHEXunvy3eXS/lbSqfNKhJrcsee2xztgMPArH7Ivnb4ASR7Vp1fRkL6MCPlSqfg PB4vyHAP8kTfUBf7PWWIaBHPo1R2pIYU8YJuNdAqpEGbkemyFBpOML0Vc4Lx/yJ1jjyT cS4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wzcLDAyd95h6i84x4LvRo6vEOIrvut9FdCnT+zIoJjI=; b=3AoP9HORU2JQ/FlWDZHsTxdySuwGGqn7iDBQcLn4FmyMIT24yvmxb2vtsv10L9LuQR laHOWEIJ25eyIRUDQK36TXxZgb2jBLzqGnh26W2fElKsQbHpb9PvUp6Dvyh4uVbtwSBm YWCt51+reVL9+px85k0T2uJxF05Po6KPGG046DJMRIn9yaVcqPpdzRa25dWZ5SrXj0im ugW7qXJxp0GYOBTQiJPDLy+6/qzg7OPrAkotOeKcFwDh4nziY9Y5MfFh7FVUGwVKj22w 3rj16xww5r8SAbKs2mCe/efrO4hF+kF3K/nr1GHt9ui3q93uTzQn4f+XoI3quBG5FmGj 6gBQ== X-Gm-Message-State: AOAM531xFtMfGpjtGOpJGIfQd9ZuauJnDrSxQGJ9R1kVNPr97Rj0aOYJ jLrUsNSiyDHliRa1Cfj1OrmsBKsdWzKBnYhQC+o= X-Google-Smtp-Source: ABdhPJz6vWA+skheBV70428MSk+hsB7E2nyhr8CfWTDWSczSNQVZN5GPuQnwVvYyk1VZbdkOH2GLFbeTHmjrzMhwVGA= X-Received: by 2002:a05:6870:5802:b0:de:ce5e:33ea with SMTP id r2-20020a056870580200b000dece5e33eamr1314904oap.57.1649161888874; Tue, 05 Apr 2022 05:31:28 -0700 (PDT) MIME-Version: 1.0 References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> In-Reply-To: <83fsmreox8.fsf@gnu.org> From: Philipp Stephani Date: Tue, 5 Apr 2022 14:31:17 +0200 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) 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.8 (/) Am Di., 5. Apr. 2022 um 13:45 Uhr schrieb Eli Zaretskii : > > In practice, though, malloc probably won't fail at all -- more likely the OS will keep handing out addresses from its 64-bit space and slowly swap itself to death. On Linux, the out-of-memory killer will murder some essential processes at some point. > > You mean, Emacs fails to know when it approaches the memory limit, > and/or react reasonably when memory_full is called? That'd be a bug, > IMO. I think this is just how modern OSes behave: they will happily hand out arbitrary amounts of memory and then kill processes without warning if they use too much memory. By design, there's nothing these processes can do about that. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Apr 2022 13:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Philipp Stephani Cc: luangruo@yahoo.com, mattiase@acm.org, larsi@gnus.org, 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164916439016619 (code B ref 54698); Tue, 05 Apr 2022 13:14:01 +0000 Received: (at 54698) by debbugs.gnu.org; 5 Apr 2022 13:13:10 +0000 Received: from localhost ([127.0.0.1]:54090 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbize-0004Jz-I1 for submit@debbugs.gnu.org; Tue, 05 Apr 2022 09:13:10 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbizd-0004Jm-2E for 54698@debbugs.gnu.org; Tue, 05 Apr 2022 09:13:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60014) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nbizQ-0008HL-5L; Tue, 05 Apr 2022 09:13:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=yo/SyAAkUMh0aoQwhypU74zhxjIbsMvLfmkRwV604/M=; b=EWHsnc+vSD2ThXCxGiJL JZZjO7Adte2WUr6iqiFz2ykTmAbrPeNTgITQ/yrLhcvMENzvLc1DCAOTP60FXQe5qzJGA7X/D/qKm +NndT01yqdIQfN7fM9WBRhWqiRrj+RteoC53CSjF9uWoFOYAVxlJXGVaa3Na20KePQpjvAuOO/smY CamunySz1w1WPWyw7eyImapNfHHnQI++lvH6I2ttGpAHTUyPcMkDqCbt+DiCYRD97eg4cJRxr2qi6 Hs7Wl+CG/bAm5yFTb1oix1IIx6l/Ys5kK7RgmePFDRYkk0qxU4sOwJ1SIinKU/QeVkX7yNIZDZ2SN 0PQFVuX9HD/11w==; Received: from [87.69.77.57] (port=2270 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nbizP-0000FA-Ak; Tue, 05 Apr 2022 09:12:55 -0400 Date: Tue, 05 Apr 2022 16:12:59 +0300 Message-Id: <83a6czekro.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Philipp Stephani on Tue, 5 Apr 2022 14:31:17 +0200) References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: Philipp Stephani > Date: Tue, 5 Apr 2022 14:31:17 +0200 > Cc: Mattias Engdegård , > Po Lu , Lars Ingebrigtsen , 54698@debbugs.gnu.org > > > You mean, Emacs fails to know when it approaches the memory limit, > > and/or react reasonably when memory_full is called? That'd be a bug, > > IMO. > > I think this is just how modern OSes behave: they will happily hand > out arbitrary amounts of memory and then kill processes without > warning if they use too much memory. By design, there's nothing these > processes can do about that. That's not my experience. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Apr 2022 04:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: luangruo@yahoo.com, mattiase@acm.org, p.stephani2@gmail.com, 54698@debbugs.gnu.org, larsi@gnus.org Reply-To: rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.16492181721997 (code B ref 54698); Wed, 06 Apr 2022 04:10:02 +0000 Received: (at 54698) by debbugs.gnu.org; 6 Apr 2022 04:09:32 +0000 Received: from localhost ([127.0.0.1]:56637 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbwz6-0000W9-Bt for submit@debbugs.gnu.org; Wed, 06 Apr 2022 00:09:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34104) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbwz4-0000Vx-Uv for 54698@debbugs.gnu.org; Wed, 06 Apr 2022 00:09:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49426) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nbwyz-0003eF-Bt; Wed, 06 Apr 2022 00:09:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=E5E3ro52hOVDjglP8jQuc3nT15m4tj3ZoZLySTiZpuw=; b=pFCgE0Mi/Qq+ /qrla2xuMooftF04HHVa4o4cnLwsgBsiuxE/+Ub77WJJXbr12i5VrKM2zulPNEfqD8DwthCh7wkKa sDBTqdTvat+OLenGzesVRS8wlHPWC/VwjnQKKPqGbCcx2lyERTZGQSznbr92B4U5Wfn8bPunygni1 +oDJhcteqJZIZjW9L8RWeZZ5Ak5LPYbmfif4atdNjrxuWgqnmlsvJ5f91D3Jf1SvMePS4z5X4f0Xv oJKaQbS5Rv45/72KwMk+5zSvQSfuz0b+zHucIRIClC+qszx6fb8zPz2PxwJIeGybbPvY3ZRW1QuAz KCRzw7KYldhxTym+KN6lTA==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1nbwyz-00024C-3T; Wed, 06 Apr 2022 00:09:25 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman In-Reply-To: <83a6czekro.fsf@gnu.org> (message from Eli Zaretskii on Tue, 05 Apr 2022 16:12:59 +0300) References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> Message-Id: Date: Wed, 06 Apr 2022 00:09:25 -0400 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 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > I think this is just how modern OSes behave: they will happily hand > > out arbitrary amounts of memory and then kill processes without > > warning if they use too much memory. By design, there's nothing these > > processes can do about that. > That's not my experience. A few weeks ago, when I had too little physical memory for a while, I found that my machine would start thrashing, and then Linux would kill a large process. Fortunately that was IceCat, not Emacs. A wizard told me it was indeed killing processes without warning, but at that moment the thrashing process had no way to receive or act on a warning. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Apr 2022 05:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: rms@gnu.org Cc: mattiase@acm.org, luangruo@yahoo.com, p.stephani2@gmail.com, 54698@debbugs.gnu.org, Eli Zaretskii , larsi@gnus.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164922410712966 (code B ref 54698); Wed, 06 Apr 2022 05:49:02 +0000 Received: (at 54698) by debbugs.gnu.org; 6 Apr 2022 05:48:27 +0000 Received: from localhost ([127.0.0.1]:56682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbyWo-0003N2-KS for submit@debbugs.gnu.org; Wed, 06 Apr 2022 01:48:26 -0400 Received: from smtp-3.orcon.net.nz ([60.234.4.44]:42117) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nbyWn-0003Mt-Ja for 54698@debbugs.gnu.org; Wed, 06 Apr 2022 01:48:26 -0400 Received: from [10.253.37.70] (port=57397 helo=webmail.orcon.net.nz) by smtp-3.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1nbyWV-0007dm-OD; Wed, 06 Apr 2022 17:48:07 +1200 Received: from ip-139-180-65-103.kinect.net.nz ([139.180.65.103]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Wed, 06 Apr 2022 17:48:07 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 06 Apr 2022 17:48:07 +1200 From: Phil Sainty In-Reply-To: References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> Message-ID: X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- 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 (-) On 2022-04-06 16:09, Richard Stallman wrote: > A few weeks ago, when I had too little physical memory for a while, > I found that my machine would start thrashing, and then Linux would > kill a large process. Linux does indeed have such a feature. There is a description here: https://www.kernel.org/doc/gorman/html/understand/understand016.html I do not know whether such a feature is common to modern systems more generally, but the above article says "This is a controversial part of the [virtual memory system] and it has been suggested that it be removed on many occasions", so I don't imagine that it's considered to be a standard approach. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Apr 2022 11:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: rms@gnu.org Cc: luangruo@yahoo.com, mattiase@acm.org, p.stephani2@gmail.com, 54698@debbugs.gnu.org, larsi@gnus.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.16492427576750 (code B ref 54698); Wed, 06 Apr 2022 11:00:02 +0000 Received: (at 54698) by debbugs.gnu.org; 6 Apr 2022 10:59:17 +0000 Received: from localhost ([127.0.0.1]:57108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nc3Nc-0001kn-Pg for submit@debbugs.gnu.org; Wed, 06 Apr 2022 06:59:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40358) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nc3Nb-0001kX-4q for 54698@debbugs.gnu.org; Wed, 06 Apr 2022 06:59:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53880) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nc3NV-0003z9-He; Wed, 06 Apr 2022 06:59:09 -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=MtDJH4Zu/1GLD4c0lcwzslVZiAf+KITUk43I7xW2SJU=; b=IzzeXQUWNuLp CLJtff/bbibpNNfe4YuczM20SCqsoD6Ns7yinNrmE0nM/VGcWNEXGWrUPwwg2Ed68FuV5WTptG3JA ONi43FEh3JiszVgh7dUL0+mPo8txGOXV6LyewndlnhTWofuOndFIvFX5z15QUSk/tvg5YF3t3grtB CXGwHBtBCDDwPg2YWcrtJ4Ryc+nCk4s2Cw1EFJP/M/FC9PT0EqPLGTrs78adX1QvVxKRTfBXcTjnz 77qro+df04+elX2t1Jjo67HrzFt5WobZ41nB16Vd2TU+VWL6mF1DBHrpAM1HJuS316zBXjUPkppj5 HMUkmN57wEHpYAA7HEvyZg==; Received: from [87.69.77.57] (port=3860 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nc3NN-0003KL-Nn; Wed, 06 Apr 2022 06:59:05 -0400 Date: Wed, 06 Apr 2022 13:59:08 +0300 Message-Id: <83r16acwar.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Richard Stallman on Wed, 06 Apr 2022 00:09:25 -0400) References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> 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: Richard Stallman > Cc: p.stephani2@gmail.com, luangruo@yahoo.com, mattiase@acm.org, > larsi@gnus.org, 54698@debbugs.gnu.org > Date: Wed, 06 Apr 2022 00:09:25 -0400 > > > > I think this is just how modern OSes behave: they will happily hand > > > out arbitrary amounts of memory and then kill processes without > > > warning if they use too much memory. By design, there's nothing these > > > processes can do about that. > > > That's not my experience. > > A few weeks ago, when I had too little physical memory for a while, > I found that my machine would start thrashing, and then Linux would > kill a large process. Fortunately that was IceCat, not Emacs. > A wizard told me it was indeed killing processes without warning, > but at that moment the thrashing process had no way to receive or > act on a warning. You seem to be saying that Emacs on GNU/Linux cannot reliably detect that it's approaching the memory limit, or have already approached it. That'd be sad if it were indeed 100% true, and couldn't be alleviated by some system setting. (I thought one could use "ulimit -v"?) Or maybe Emacs should have its own setting for how much memory is available, if it can reliably tell how much is being used. If indeed this cannot be solved on GNU/Linux, it is IMO sad, because on MS-Windows I was saved several times by memory_full and what's behind it, when I occasionally needed to visit very large files that exceeded my system's capacity for Emacs. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Apr 2022 12:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: larsi@gnus.org, mattiase@acm.org, p.stephani2@gmail.com, 54698@debbugs.gnu.org, rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164924673130016 (code B ref 54698); Wed, 06 Apr 2022 12:06:02 +0000 Received: (at 54698) by debbugs.gnu.org; 6 Apr 2022 12:05:31 +0000 Received: from localhost ([127.0.0.1]:57196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nc4Pj-0007o4-Im for submit@debbugs.gnu.org; Wed, 06 Apr 2022 08:05:31 -0400 Received: from sonic304-21.consmr.mail.ne1.yahoo.com ([66.163.191.147]:43776) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nc4Pi-0007np-9R for 54698@debbugs.gnu.org; Wed, 06 Apr 2022 08:05:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649246724; bh=zAgeT0hG+Ag30m1iHyjXj5feVbKwkGB3NMhPFR18qYU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=Bfh1mxBNVBFaSFgiexrJf4NbqyjtAQ2QmpXj9hoQslKQQKvS2nMWOPl8pzrjFpjyeNzycSrq9eFaNse7LBU3HADcJ55HX7Nh7ASAqndjdcQ3bSDYOUHY0XwF/i0YYdLlturNtAAKFhmWqjJ05evE/cbRBeLeka+D/+ElkPw7J8kpqx5ny+dMOnS1Kr3uYT0uOBbiLHyQNf3wvsQLt3NnR6ytsOfV2XbocFOQPp/nc/n1jzms8XP48InlZanhDn0EU4rC6C42ZF+6kVpz+8h4HLJU+Ak85X4xyLTNdigrWNUiFKTC/0sygGxtvO9Z8ypH76+ewdiXWXIdloFEqpfwkw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649246724; bh=qdTzudPntGPLeQUjigfmLrluS7GLlvASi11eivO7yoz=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=ECoIeSl5/CUnGnRBXHn7OXbysgO8+eJRuJ4kHOEhj9m+wBvp+qI5h2zQddTdK2cAcQ4hfGje5wE9T0+NqiQYsh6IK9MeqE03va//x3AxxwzWcQbm+raATMPwOfK7HzcAOH8Q/0+YfahzKf7f2GL6DANIkgm7nbfFO3nPbo0steMZYutLsCWCXZdnnLC0x+ClWXc1yoe+0llvNF0uvL0aD3p+NixQTBO8GA/NeF1eBIeYzu9CjqFDbYAQyA1hE8/cfj8n2HY5fh1lOxpTdQgP9NFwP//CM2X6djbmCKcyd0yhlxYZM7Mmecc16y/vIRQYT7wXu3urrzxdDb4YptCNNg== X-YMail-OSG: OAae5e0VM1kUytUn0aXF1gC6cCgQVF7h9QMAxFZMGMmq_kSp11HVFyMivINKvfN jMuikV9Sqhp9T9AYDWT2Mee5153_X9_xElSOLCXrtTP08uiXU4cOflhv41ANHoACbbZTNBs.sdSP i1xjzFGzF8KSev5q.TGkpui.HvUdb8XVc2UG7eUyIuoDH0PDYX76uJJiqfvEkedP7oHn8kUY71uk 4O_UzZhjsepeHM0S3Y98wZ1aRCU5VHfiCKnNE9SN_0BHz_ep6I8mY49rDqqzd9kgbgFos8AsmAs7 ct9Wlj9dMHlJPYchroCdlF.oVA099fT.GG1eRhGHxwxx8NIKmNUHacUDiI_ufomrTGBxIJSt_gBi T6rsXM3WfADcJgUEIInNuN7QSu7mZyhL8c5eR77WRF0y.EmDbCV7M9NkpWbEuLsfV4K6zyscKs1b OmY03HREP.UhBQqErj2vXxQBknmrm1mCspy0JlZIlUJePzadhWzYagKTZ9Rze.ylU_N8NAAsqZFV 0sPfq2xioubsUn00G8nDkctbL51LWO.9BNWON466fTJjd_MrxjCDgShfvSxFPI9DbYNynilxiaKz 18sOCUtWEsbM3JxVLoL7a7HBlbUEHbxaqz0O8LmQExHIJUAxl3Pie2wKnh.KRn29pdvQC._NzJt5 MCUiPkY6kBHrj6ctz6s.syuxNfZXZYKuGEjqz3SFoO3W0D9XL1F1rQ1TxYwA42mb6di_2zVg650p 6sB0akwCGFoxFljZzlRGQ3VxHmUNI1nqc9EC1wRTgxdNyTuOqWUDEx0vKST7loexBJQH8HBFfb1Z oChTifpw7gs7GdRWdZuHEdHKyrfuSaU95OjnjjEgCp55UgVI1OkP8mlG.wwJLo9Xbq.G_3lkfxnf jzf.CFbYLUkeOdQZ_YagLuQgWq8kP7dtwi7UiE7tnWuyg3bUgOmgymRSbwWRizxbL.X3qKs_Aiom leZvKan9KqYM.iSC0G18MUk61_27HfZkeYI6KrG3vtcmpsYn.AVl7wrCy8PfncE.dLNCB4Jkk3Bs nvVc5E8WAVett27q61Imp4qGrZSkZZpJskdgevSrlBAWvdDPVGgRRzrbFPlvPht6aUSzyR1Gbu7C N3HrOwJKOi9d4Ke4ZbCM0QZLv5Bd22wLXqoBvpRRllwpBw97Zkyns0.O4nL0J.n2DIcpIfMdg79m eTXlt9wtBrpZieNrZ2qJytSwcj0kbjzjYyxsA6ukUd3K4U45yBMdsATo5UqoF9YV3AZsI0z13p5e JtbvhbbGOMPsp9w2T1E46zIHq1vP5ZPX2fjkmobpmGfQ0j78lbEpmipAXCOiWNdhYo7iaQki21q2 J0.DZBlVNSI3Bi4jOh3NMsDqzkGiwcPqw5a2us92uw8Yy8xlLpy7ALMsbFMTneKaPQrxpZ4VGgnZ 4_geX_IJBkXluC27o.tE84i_Dsd0Q92YHl97oUFgzOnVTiZn7FoH0egoVHvKBbWEpeaOl.E55kGC ssKnYtB.xgOapud1phakLsN_kPtD_RtGBKX5I0U15gj9_zc4YGCLxhST2qgO1XTfIwkx6GuEM02H mKorUEHRPF1xWL9MfCQTsjSBhz4RwzUJL7f3fNWdkBgWF6BhJpIPsOWyI8SS7COFCXkiDD3LHLfZ DPWPlaDenU0CsSCA_El6Yone44WwhU5_nRUvQ09muW4jX0DHKKIUT4Euir6s3QuQBwNfBhNkhAM1 7kp89y1Pd_9HAzp2Uwgv54Td9Qn6bYEYtomAuPJWEpjssKB0gkj1zU9vZ0buFp7tZULwBdpEslQP A2oZkypFS8dIKQulwPTJhQ71juTz7yKy4B_JK0nbSOqKJnX5pBdnCvJSS7aJDLwhUXQGxkalMfVk t44k28QavabDQNCkAf9cbzcIVgyeORJfq8CwdezzQmJgeLXKTI2CyQjVRoczpCP5Kfw0N_Nw2p4j RfiSsRmqmjxY5uwNo8FWDhsux7jGO9LF9ZNMZLWPy70ILUGBl5MjjXWooWrMpaFbuRRiNQi7FJHq i_.QyBL_h11.K3lLdtBloN2.5coI6ma5ltkM2_tSSJIxSZY9SdHshVUVLqHyeacOSZvXh9FRcgis RBbhSD7xQrtoA0M8B1t47OLLPoAwlGlyyr5nzCPZormqjzQY9FG74L0XhN3Eus..KnoJRLuh0w7o .O5aFraTx5heOxUvJcGIMotaD3asHTp0wjQVQLxxoWwSqXKhoxkOyYZacMMaYDMSc6hbTBFpD7y9 RFn8FtgVpkoAvN8rhBeLi2m64JDMZuM7hcLY8EacwzzjaAhkgWExiGFb8bav8sudZmiHIZSTr3w- - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Wed, 6 Apr 2022 12:05:24 +0000 Received: by hermes--canary-production-sg3-65d7bd97b5-r89m2 (VZM Hermes SMTP Server) with ESMTPA ID d6f603bfb735ef98805e96c4f56bc4be; Wed, 06 Apr 2022 12:05:20 +0000 (UTC) From: Po Lu References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> Date: Wed, 06 Apr 2022 20:05:14 +0800 In-Reply-To: <83r16acwar.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 06 Apr 2022 13:59:08 +0300") Message-ID: <87tub6zabp.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20001 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 994 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 (-) Eli Zaretskii writes: > You seem to be saying that Emacs on GNU/Linux cannot reliably detect > that it's approaching the memory limit, or have already approached it. > That'd be sad if it were indeed 100% true, and couldn't be alleviated > by some system setting. (I thought one could use "ulimit -v"?) Or > maybe Emacs should have its own setting for how much memory is > available, if it can reliably tell how much is being used. > > If indeed this cannot be solved on GNU/Linux, it is IMO sad, because > on MS-Windows I was saved several times by memory_full and what's > behind it, when I occasionally needed to visit very large files that > exceeded my system's capacity for Emacs. Overcommit can be disabled on GNU/Linux (the relevant knob is vm.overcommit_memory), which will malloc return an error when there is no more memory left on the system, thereby triggering memory_full. malloc can also fail when it runs out of virtual memory, especially on 32-bit systems. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Apr 2022 12:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Po Lu Cc: larsi@gnus.org, mattiase@acm.org, p.stephani2@gmail.com, 54698@debbugs.gnu.org, rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164924780231718 (code B ref 54698); Wed, 06 Apr 2022 12:24:02 +0000 Received: (at 54698) by debbugs.gnu.org; 6 Apr 2022 12:23:22 +0000 Received: from localhost ([127.0.0.1]:57223 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nc4h0-0008FW-0O for submit@debbugs.gnu.org; Wed, 06 Apr 2022 08:23:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33202) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nc4gy-0008FJ-Dp for 54698@debbugs.gnu.org; Wed, 06 Apr 2022 08:23:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55234) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nc4gs-0003If-WA; Wed, 06 Apr 2022 08:23:15 -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=dvRhhoCsN8Xkc/nfovOwg+/gYlCwWSYLASB0YB8GIV8=; b=IwWCIDBiTGMK INslfDl0lg9Jmw1RBm2BYfc21uKB0ZdP46DdSU4tOC6XLpCTWsyy6joPWDDxrdPA8PytGDqUvjkPP MpZNfgvoO+r1lRl9kstQviWFFFmlrwHJh07t85OEjMcW0p7z7S9KBNCVYdoOB7pdAehAVR0srYmFw /opP3Nnvr5SBj7Lo47CFacvGR+NnpnGek0bH7rLnux4/uV1n6Ddahp4MPSis+VX2etcswjCXmF51i A09N//PZ3WbKpCW22PhUogePEnj18xu8tCSGDiThLrRVqBt+E2fX7jBnfTqSrD5JcauDMvCx1TZtB 0TpdhDHRZxxCdslCE+SvAw==; Received: from [87.69.77.57] (port=2054 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nc4gq-000435-NS; Wed, 06 Apr 2022 08:23:13 -0400 Date: Wed, 06 Apr 2022 15:23:20 +0300 Message-Id: <83k0c2csef.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87tub6zabp.fsf@yahoo.com> (message from Po Lu on Wed, 06 Apr 2022 20:05:14 +0800) References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> 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: Po Lu > Cc: rms@gnu.org, p.stephani2@gmail.com, mattiase@acm.org, larsi@gnus.org, > 54698@debbugs.gnu.org > Date: Wed, 06 Apr 2022 20:05:14 +0800 > > Overcommit can be disabled on GNU/Linux (the relevant knob is > vm.overcommit_memory), which will malloc return an error when there is > no more memory left on the system, thereby triggering memory_full. Then I think we should advise users to do that. > malloc can also fail when it runs out of virtual memory, especially on > 32-bit systems. Why only 32-bit? If overcommit is disabled, isn't the amount of VM determined by the sum of physical memory + swap space? If so, you could run out of VM on 64-bit systems as well, no? From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Apr 2022 12:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: larsi@gnus.org, mattiase@acm.org, p.stephani2@gmail.com, 54698@debbugs.gnu.org, rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.1649248508375 (code B ref 54698); Wed, 06 Apr 2022 12:36:02 +0000 Received: (at 54698) by debbugs.gnu.org; 6 Apr 2022 12:35:08 +0000 Received: from localhost ([127.0.0.1]:57234 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nc4sO-00005z-Bz for submit@debbugs.gnu.org; Wed, 06 Apr 2022 08:35:08 -0400 Received: from sonic307-56.consmr.mail.ne1.yahoo.com ([66.163.190.31]:40859) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nc4sN-00005Y-F3 for 54698@debbugs.gnu.org; Wed, 06 Apr 2022 08:35:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649248502; bh=PFMvFPWybhNjwUDAQmpwcUFppZSi9xFR8aUYOqa1u/0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=ZNDmNm7lmy9ZAihTyWmdR0KF7NcFh8isJSRewAnHp+ZjVYNBoPXgMs2f3k/tc4EYEL6lXu9KEHqs7L5/lJeAn9tszegK4eiexzqbkJJt7PNCfZ6BhwtFYbAM8hVul3o1lTUq8nMFirjQxe+/0F1r6OAjRTTV7TtkzYqvPO8NGzUx0EZO8itZtDpd0lMCsdn8WQmn8QcIbgISyngNtdWFm0vvURn+bEKQMTrJnoDiLmHUiVukyq6ydYSs4q2aIm1Yq3gMQBi4tzERwmfqLY1AJ4v4Jl6qEigQUSH90jMJ/jsPXP9ujydaAA3KRzey/TFDiGQaSI83kkRgkWrrcf1FKw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649248502; bh=DFqdEDge6BFGeKJd+yhFX7hnhWu4b9l6pbGIJLmn6mx=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=jMehItNJg62yTT3htc4EcBcdEaOCEP5GfAqtANjcC5EPMALNSEJI0A/iu40FaBNHUsObH4uRhklmBjjpq4301JX3DGhqVYH94P8AKRPjH/myV9UkI0OhOHY2jgUC7S8+eE5ulYT0HH2QGQ/t7U909bGBw4pUzpSJgEe2SywSZI7RxVPs4fCvlVjFcXg1i+eG6NaDARV/SiMlH2ROrNQ/7FFnrD9via3b0lXX9TAuw0uw0ckdmwTghdmytTNC3shNb3xDw39VheapwCdE6f+SUECc9SdBqhCBj4xdHUwky+y3tP0JaDVUzF1CgTyDPJZo750mFxsFwH8+h8W7i0X67w== X-YMail-OSG: ZXYua.8VM1k1Q38qx_WWqmrUVEjml2GqgCWN5ghlOT6cnjTqWdjMu0sqLURfpBX ktvn9RQgCd9Lf6gWqnSO8FXCAJS4QwusA2DfL20XTlH9Adaah3u6Dqf33xHaNqTJRk_CgAjmzY5p EQmk1bUACHNqPJfgVK8PnsyZEg.tWiUH3eGWQQeozjboB1i5ihVh6TpklZ4DVcV7mfYX0bCpmEmL bQqp2SisJWGB2PBwYxtVbQoM0M7X1LCYUg0qXXLQPNQ64IeIeCHMk4VpgglAs6dvDc0DnXSTHPqP uAXE_3SUwsF64YFuY_WkER13RjMMFqNlMdb4WLY_JyiUZTEC1jrbe.FT_xvV7a1L0oMw7DrbE_98 kwjYbajC5mVQQJxkhd_J.qxHmYgyMDz3J0niT3gpxjM06akfAAgQj8iBlCrBIw7dw0y2fZmKbHSn gvtdXytw3id5r2nKP2UW.KJNKeRDNRuDiRRSPQogtDkRDshJNTh5no4amDkrgFGhUeRMPmj3qzko w9yzb_.G1OCvMofOTOykg_MW71mxGIm6Z9x2O1S8GP1gsg12cX78on49pESzQ8Ae3uiut0jO39zE Q0X0KxFYSzuXjfY2paiNGSNtOyPJWqNrUk8faQiVC8Rd8ZhR72UuSml1r3iHArQQCyjnvI3I5bSR FMmV88C9SJ.ymUQSCXo9sM3tvVrk1kMP6JBpQDf6r3Y.DZPYJIacLf7tticKfjzdUfs6iOBN5rOH RyPxRnyLYEFZGH7HA5lkWkUnSoo6D9rzfr75EK9iOB6stEqVYBqFHkabgMHTtTWi2kxvxeUzpRol VjiX8SAxW6hwcqFl.on.EkHJXdG.xve5wvkcNWSKjY6IbQsU40.GV7U0S08rQ0egIkQHT1yghCRc .3gRGf9fEPHFEURHdICwbkNvXKN52D_61.qflw.SjduLlEOFtqBbo_PBW5RrbDYTPIVmRz7X7YtV JjtEi05s9Re09j.odV0YVIsAT9.0pQG1_9mPqcZnaHNGzzTRtvRVdfMhMMDsaLFKsFnaTBDJPxJh fvO3ha0saboPUA3.CUkyZIKtv4GpB_ZLDAaU4gT_sDHtH2ce6IJI3jZ2WZSPEGyNkxFA0Q5zPCkD KifWnp2RmtpXeWiMqIC1gB3MtINqO.NfSKSHc7P7grnKc9zamceVZdM9Yjd_Oy4ju7LOggUDajVh Zh._VdK5S31idMNE8KkBP3VVJlDCV57KUDfXMuiJhOXiAVj7Zo8JmpQCztUGWJ1GULzzrYoDGdu4 EAsOY11fVvPOpLSmFu4dM6rmxK1Uuq14mmBduGYsLI5QQE7VpFKMq6UrJ.Cb2ifC0BU_Ty2GNapW OrnE_cTWMo7gbG1Y8KfQZHsnSl7HdDMjNHMJ1QJJDAOft7BEuZxXvZToGJ1DOe_DYIV9ZTMJwdVO ZwELxoOUCizqQoJfSeux1z9d6R23w3YtSE5XIx9ZiF4xHTaZ.ujqffOsAb9Qm68n5oAwCLPToimQ o6m3JpBt3_eb3DUVtqJNHDPK8QHRpspdVMIB1DZXE8FloYU_48ALBmCHYDzyMk2bh67VC.CMSr_. HWm24WcnoanGz7v6BYqaruVyyy8wMlyenZTAUJBjiViWOacsWc5nUzaTlAgZHA1wld2lR8B580eg fSKFYMCnOmc3OkHf7xqPCX8CSQ.tNonN13xxvg3s1r1ZoA.TZBD8YxuLpOCVJqjlCZJ.Z_b4zGQC xkCrQrW3Ib.CK2isiOH9vkD5ZKENc4rEJgi5wXP7TN6gfUbPnG8GNrkcqHbqDv2wgFEkv_x3AIJm NPmO11lQprMlYhx5TnxZoucRNOnzgUheSu02KJH1hQMiFl7eFqhuZFt3HORlLLIfSHH1VqULJqJB 2pEA69VjMRzEWdKzddf70kSVNw89WgSO4xbdfSVvtbGBkFmJ6QNeq7U.M33FoiKSNpkCIVl7tttA A.cNHDh87yzL5ywis5T_NCIa2b5Wqhd0m2BXAjc4ALDzaolfe51L43OMcPj2E_t2qO1n1o_LZtl3 O87wegQjdn0_LZ9T0OOnAbVzAFN04Ob8u1FAsDjKw1u6LFtmAxrm64CYi2MmUjKfpjZxdRK5Zw1D xjgSe_SOmD281oUBC5y.aTHG9MWyX7WKr3dhuH6pO_VfuY6TgDKPZPHbCTtRWmQSfdqlaCkdb10G XUDJedJNBCCLxckRCFsuvuf0va5h_QXESOM_JgBobl66iJLIPwJUlyRrxaLifuKyzhyeu8nMvtNf V8rBfcF4XYbJ70fOnv9H6.hjODlupwY0dFxc7AJgXZtoSHhtkTPbHk9kE1tOQs61osDk8WVJA X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Wed, 6 Apr 2022 12:35:02 +0000 Received: by hermes--canary-production-sg3-65d7bd97b5-rvrjv (VZM Hermes SMTP Server) with ESMTPA ID 217f0823a93e9a99c25a3c83c8dbd790; Wed, 06 Apr 2022 12:34:57 +0000 (UTC) From: Po Lu References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> <83k0c2csef.fsf@gnu.org> Date: Wed, 06 Apr 2022 20:34:52 +0800 In-Reply-To: <83k0c2csef.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 06 Apr 2022 15:23:20 +0300") Message-ID: <87o81ez8yb.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20001 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 584 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 (-) Eli Zaretskii writes: > Then I think we should advise users to do that. Sure, where would a good place to put that advice be? etc/PROBLEMS perhaps? Thanks. > Why only 32-bit? Not "only", "especially" 32-bit systems. They tend to have less virtual memory available, and the amount of address space available to individual processes is also very small compared to newer systems. > If overcommit is disabled, isn't the amount of VM determined by the > sum of physical memory + swap space? If so, you could run out of VM > on 64-bit systems as well, no? Correct. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Apr 2022 12:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: Po Lu , mattiase@acm.org, p.stephani2@gmail.com, 54698@debbugs.gnu.org, rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.16492495762546 (code B ref 54698); Wed, 06 Apr 2022 12:53:02 +0000 Received: (at 54698) by debbugs.gnu.org; 6 Apr 2022 12:52:56 +0000 Received: from localhost ([127.0.0.1]:57336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nc59b-0000ez-QS for submit@debbugs.gnu.org; Wed, 06 Apr 2022 08:52:55 -0400 Received: from quimby.gnus.org ([95.216.78.240]:36970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nc59Z-0000em-WB for 54698@debbugs.gnu.org; Wed, 06 Apr 2022 08:52:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References: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=8OpdjJhKDWwp5GfcY1mpvl9MMv14BRcQveKLZ8mMMRk=; b=r0RH/jF49s5k4wmdL0oP6MCQMm Sk1NG3Tq2hbLSq1+PcOR4Tam9zA4zWrPN1OobePdyXszWEZYIfsOtXHHKcpsm0Z3bxKpYkvS/Twzi WqbwggsnElpgvgbCeNfBFIPGa8v70EALnOqsgmrUUYXhp2iRQRI2LGyCkaoYlK8fDkZA=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nc59P-0003Bu-IX; Wed, 06 Apr 2022 14:52:45 +0200 From: Lars Ingebrigtsen References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> <83k0c2csef.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAG1BMVEWooIuUhnttV2hO MVCHdHPX16PFuJJ/jYf///+iN7AsAAAAAWJLR0QIht6VegAAAAd0SU1FB+YEBgwyO4lD7xIAAAGh SURBVDjLddM9b8IwEAbgC5SwkpbSNT1TZjhHndvUqCtCcmYUGs8ZKvXv984OweHjhpi8T3zngIBE 6VCybm1fcMqfn7Te2Ai6fGL5ifU1vFmBzT2gayBbaVK6uQ1fajIA7pGDwHhwXL06+hE7TXtZe8jt UQ7LUOzpPYKm6XcccRWBcwwcyHDcXsLaA0anqjqo3I4U4XmDYxiT8oC4iSF1I1JF1dQRVNY5gHSk dWEPChHJuu55Aag1kauJdxSVh8oF+CFNKXdSuHCu6XIB4EwAqeEgxAEQ1armnCSwZzjw2HzEF3RR AbiDQZOjMYh8w++VOln8cHkaNWI62AG+i68LeLwHZQ+Lc37odoQxqRw+DWm8YxnuTzkP1wFyGJY/ 1YjuAMoPiLMB+Bm5um4WooeZGsJfAG7CvT5iaKU5yiyNIZpBkmVgvpW8XivDXvmSQOYLeKzSivoO WXYCVPL/9F3aZAD8CgJTaTNLYkCGYjpt4QUghlKAfj8N3/Z52IEChitkc/4w70EW88np3PgKoPwX vyyN6eITdFUujbkJvOkeYA//lFThvJ/ca+kAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjItMDQtMDZU MTI6NTA6NTgrMDA6MDBvPnMIAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIyLTA0LTA2VDEyOjUwOjU4 KzAwOjAwHmPLtAAAAABJRU5ErkJggg== X-Now-Playing: The Bunch's _Hard Luck Stories (1): Sometimes it Happens_: "The Locomotion" Date: Wed, 06 Apr 2022 14:52:42 +0200 In-Reply-To: <83k0c2csef.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 06 Apr 2022 15:23:20 +0300") Message-ID: <87czhucr1h.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> Overcommit can be disabled on GNU/Linux (the relevant knob is >> vm.overcommit_memory), which will malloc return an error when there is >> no more memory left on the system, thereby triggering memo [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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 writes: >> Overcommit can be disabled on GNU/Linux (the relevant knob is >> vm.overcommit_memory), which will malloc return an error when there is >> no more memory left on the system, thereby triggering memory_full. > > Then I think we should advise users to do that. I think it's outside Emacs' scope to advise users how to set up their operating systems. (Especially after three decades of Linux -- the kernel has always worked this way.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Apr 2022 14:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Po Lu Cc: larsi@gnus.org, mattiase@acm.org, p.stephani2@gmail.com, 54698@debbugs.gnu.org, rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164925425411587 (code B ref 54698); Wed, 06 Apr 2022 14:11:02 +0000 Received: (at 54698) by debbugs.gnu.org; 6 Apr 2022 14:10:54 +0000 Received: from localhost ([127.0.0.1]:58889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nc6N3-00030o-MD for submit@debbugs.gnu.org; Wed, 06 Apr 2022 10:10:53 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38494) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nc6N1-00030a-RV for 54698@debbugs.gnu.org; Wed, 06 Apr 2022 10:10:52 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56348) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nc6Mw-0007vT-DD; Wed, 06 Apr 2022 10:10:46 -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=sDM4R4JkYo4l8I/eEz6XtMAEeJsMvZ40uS7uMjMb0CE=; b=C66j9HfylXTl D5OFTejqNSn4dvVbJb5FccR5Tk8b7/AiXsuSe6W3/wMKVQv1kJC0sJLrahexItaPyqR6K/Agn0sxU voHzazLKOdxoyX5isCLCNVneWiFn1B3vObxBaU6qkfd73tU4YRxa6nW8bWvpTcXEqqYq3D4MwMeMr 4CrYPQb7kqV1m0kF5z919Xresx8wxhdvGdbcdjc01XswTwswZiB0ZNbnXdFwHANF+eQ3weu/EaPez h02qi3bV7QmZDx2Cb5isF0MGeWWXK7fqWAkLvT45TAGyfGb4Sp6paIQDyfYi8qth27sya5W1nI9if G/lG4kOJknK46AT4ec/2ww==; Received: from [87.69.77.57] (port=4782 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nc6Mv-0005Nx-FF; Wed, 06 Apr 2022 10:10:45 -0400 Date: Wed, 06 Apr 2022 17:10:52 +0300 Message-Id: <83ilrmcnf7.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87o81ez8yb.fsf@yahoo.com> (message from Po Lu on Wed, 06 Apr 2022 20:34:52 +0800) References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> <83k0c2csef.fsf@gnu.org> <87o81ez8yb.fsf@yahoo.com> 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: Po Lu > Cc: rms@gnu.org, p.stephani2@gmail.com, mattiase@acm.org, larsi@gnus.org, > 54698@debbugs.gnu.org > Date: Wed, 06 Apr 2022 20:34:52 +0800 > > Eli Zaretskii writes: > > > Then I think we should advise users to do that. > > Sure, where would a good place to put that advice be? etc/PROBLEMS > perhaps? I'd first put that in the node "Memory Full" of the Emacs manual. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Apr 2022 04:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Po Lu Cc: larsi@gnus.org, mattiase@acm.org, eliz@gnu.org, 54698@debbugs.gnu.org, p.stephani2@gmail.com Reply-To: rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164939184816846 (code B ref 54698); Fri, 08 Apr 2022 04:25:01 +0000 Received: (at 54698) by debbugs.gnu.org; 8 Apr 2022 04:24:08 +0000 Received: from localhost ([127.0.0.1]:33764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncgAK-0004Ne-Cz for submit@debbugs.gnu.org; Fri, 08 Apr 2022 00:24:08 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52814) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncgAI-0004N3-AK for 54698@debbugs.gnu.org; Fri, 08 Apr 2022 00:24:07 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58280) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncgAD-0004ul-0R; Fri, 08 Apr 2022 00:24:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=M8vZDvwjVpyriE6Q+belcoZnDuIdEkRNnUohDvTXqy0=; b=pazKxTLX6AUh YqUBlcV+i8Jv/P5E6r4j5F5S2m3uJOOW4ls0pPvrJcAWCkEJqStKFu1CvWAJ3S/ORApsXH/mOpnFA m5tUItprTaCvBx/DESruHfpJVn1sKklhC/xSJFbXOzKm56jUml0RLdkS1Z5mrmosgoYbboj5yus3j l/PvBQev4GvtJdCbjJ/W7OHm3nqJdsJ289dCdY04vtOAFWMILPsDhMnTF4w/xMMvLXo8SsfALMhCW Nqg8FLMg4loFjuZ/1jX1cuuyhPyWIORJd2S4KFwdWFJu/ZEBy9yEjw/otrcJJVe9K0BES7rm+g5/K 8S0jPtcNc9oGMzl2jBhH0w==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1ncgAC-00064w-N6; Fri, 08 Apr 2022 00:24:00 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman In-Reply-To: <87tub6zabp.fsf@yahoo.com> (message from Po Lu on Wed, 06 Apr 2022 20:05:14 +0800) References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> Message-Id: Date: Fri, 08 Apr 2022 00:24:00 -0400 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 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Overcommit can be disabled on GNU/Linux (the relevant knob is > vm.overcommit_memory), which will malloc return an error when there is > no more memory left on the system, thereby triggering memory_full. Concretely, what is this "knob"? Is it a per-process variable? If so, we could make Emacs set it, with a Lisp function to specify the value. What is the precise definition of "no more memory left"? The thrashing that I observed did not immediately kill any process. Rather, it continued for minutes before doing so. So I don't think there was "no more memory left on the system", because if that had been the case, Linux would have known it immediately. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Apr 2022 05:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Richard Stallman Cc: larsi@gnus.org, mattiase@acm.org, eliz@gnu.org, 54698@debbugs.gnu.org, p.stephani2@gmail.com Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164939697625748 (code B ref 54698); Fri, 08 Apr 2022 05:50:01 +0000 Received: (at 54698) by debbugs.gnu.org; 8 Apr 2022 05:49:36 +0000 Received: from localhost ([127.0.0.1]:33804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nchV2-0006hE-Hh for submit@debbugs.gnu.org; Fri, 08 Apr 2022 01:49:36 -0400 Received: from sonic317-34.consmr.mail.ne1.yahoo.com ([66.163.184.45]:46161) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nchV0-0006h0-L6 for 54698@debbugs.gnu.org; Fri, 08 Apr 2022 01:49:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649396969; bh=qTzdUsx27JBKOahfCNfRNzh2MWhfRzV0i29CVOXg8Ig=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=kyaYNHLMDL39+CLl2rvx/u8yi857ABWnI5kzPeNrC1eGedI8v8715eO28ohsoahJQfeQlpjzlAG0deWnMhzp7TLVTf/0r33sprSvEesMNoSNWbq91dWctO363/5OdmxPU6+OH9IoVn/qITBg+oKX4tSO1VElHoT+snffJ1do7DbVc7n4MHO5vsRztth3i8AIAnfI5f3CCzp74y5Sb2AHFvrRASycMhz3j0FdqlQ1+yKIACtH1NyYHWN1/0H3qQBcMMMMusE+iBA77XC4qsnMtOM6k4wQIJKgYQ9m4oS2eqSLT9W3JlC9b30/6n0600OGM1sbqjLAuwOi3i8JFwmH5g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649396969; bh=VRGABtqaH/LJmu155ymB1fa3n+J1UjV9EytH5uQ3HNa=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=uhZjDiuCr0VIkdDiVdmnEP+LymnDJMQr9QBpOWHXU9UjbI9b0Qx0GL/60+ECnjFVqmblS2ivhBUyniNNqr2xQqQQ58Gbnmv/QQr6Ah5ReUjVN5SvJAY8Jxhto9yGEPDjS0VP+OdUyYIgSWMTD3KL1iB/QP8EI7emywJYW48sNoCwZK93uzHGNcZ7HgpE2XTuzFhRHVOxFKIdgbRWwQJ2gmEYdv9XXnOF586ghm4bYUfFYZDLNNTQCw1oDgUQU74FCIVdzX9CvArDN4RQB/rxb4Qjsht0vPxY9eugIVJh7LwzBNj7KJuia5I5il3CcPSk2JaRRUBV+1oeEgJeKMcyFg== X-YMail-OSG: 9q6ML48VM1kzHvGESeABmlEYw2YXnuLwRPzvQkGTIbqjrCh9SDR5gx0j1fsyPa9 y3Dk.g9Cf9XTzGPxD2QMXPYhs4TLouh5mlMVH5_Cx..CS_r3AGB15Cr86GyC9_ai6cNM7RzBf30q g6twU4wTty7JUCuyKXpJ.N7o7lstUWkiDIEmaZRv9kynyZxMO8Q.kCI02fE6O5JC8hMbtr4EALEj CAV47kifr2znP0IM78PK4gsnVhgCZGTkfeXNP9TUariGwH_aU6GsvQ0uEUlYzISyINiWlhzBRVyZ _UQa5o5LmID6oXaE2JsTNUR2xU5lpREUlFi7oQkGn.diAB4WNUJ7besSvHZDdWmp5dJC75Lzu0OY GCdtugLzM8yq5wzqUIjL1JUna_Bz.Pqlpvcl4nlQG85ux11VLHaO4dVgBdnKtBDUUBv0.C8qmcV0 UHuZpnKDb3Ldu7AizqrURwUqxYynEgz_InSwJ0RGo2.Ux.aol889oo9b9q4G9xqscxkgpSFXfXMb fH1BluFVs2zpKENhWrilVKHWrJhuUgeF4kG4XD403lG_x7Mt34fdQy33c.kTUQJlPBthdtoPSJnx vdhY7DSi13hUh2K6GLJ8Bbfq1VjTa7d7GTW_EbOKg6TWTSnrlTwNt0E6GwfF_ccLzmEn51zlA9g_ k3njpDdTV2qwRquIzna6A6Do3ihDANxpRpbbQVkmNpMYgFmLdwwQJSUAYi5vM_KhcrWK_KYx9j2L K8bD7fkppHo_r9nR698L89x36ghmtoqiKqpDI7a1bDnyq3NRubTMNiTQds_HDYx4.5awZdeM3mXR QYkGuQ4x8a9vIToOtQSyeqdfMB1T08jcHkLhjD0FiL9nvnRhrEEryGcKiFaC1uUiQojtGN0noYwV _54yahw4TblJPDDD1DZgixoxzwFi7eU7IkfFr.l82oD5pEkmS9F9C4sHh2itpe3v1RAUAnZA73Qu 03A6goGnI55KrSmfMY2xY1NXmLFhHHjoztWAsf46Dh484t.k6o1i_NlYk9_2KYB2eXiYAqacIxOq ju9NNuQuiCUY2354VZKjbDi4iV9cbQaeYcjjS9KzCz0tlqGsWSUuC.kQQbUFJguAQ5jLooIq3iOE 5EMV7WtV1rOxdBEAo4i5zjwJXxxCnr9YQu3MlZ1UsoGzR.abMIaR2v..MhlzXDBO2nzRf9pzkFtB 0TEvrlHDgi3ddMvOMgyCuI5z5WLAOa9x_bE5DqGtlPcQnu.0OIBh08McaLiCn_f_GY2zVrsPStyy 4ImfvtCRWuV0ioVDtIdyzOEHWUPE6P_BPoC5c2rZX0W2dcfnR5qkD0VUvc5YKCe3XbmQBYA.zmh9 DPG6sVyhDKwX4k2yb0qPWzfPLuZ1H09JVzoaQZ3F_3Ospr0mv44CAF4a5QWvAB5JOOBS5wgSB4pO 2pJpMNjMMA8wLLm_Aa2Ww7DdjiFQW93U5DzyA.sRp6s.ScdrJUHYOISKR7514EzrEd4xRAT9Azx1 VecJRT3kGpgHpkhDtHHe3UHt8hK_kp_yLppLHYTljYtZOrSvokBpElcNz1820EXV8pIGr9FjFTer t.cVesrhZMpzZOh9RV4sntTTJFiJ.Aa0oUOKHyM3tGVgjUclB0PHAyeorPJTCDCvEB81vORQ922n LO.TZB9kvQC7xMo4qPjbpSPbc0HyNY9T5ZqU96WThsqA5bbrLi5zj9p_hUdwj.n2IStEJoDZoxSF bARKHrvV0_vfQirGIwX54HvU2etWN0GzHuoceodNVp_.lQf6B6m4hZFXZ3tZzUEQDogHglmKKCRd o9SPqb.avSo6MFdzPk.JnrNXL2OsOl7fHDmmQnkfJRDEFalFTYx1IcA2D4MiC2HcrX1P_rtsmVim KlksnJJvtJ3bkUlKPUm5Wkm1A6L9nry1BOttabKjzVLb40LLwjyor4wqCJL3M05BnmXAEtKENFfv RSqfYEoeqNhznylzW4rAtUnyQY.2lCxX6mvGryzTMGNh5mi75JrgIgmbQa_oLjSBoMqbFMpjxJXD XIVpDiuSz3Wh6ImSZgEcU8m9kMpWk7ZNxhnm1uPFR5FmiJxcGyMMfuElPQtHbIb4XiZC8jbzAINk ezam59aOifTODgAtuuWDax3i02W3.GKswj8uAbdJPnoVW44JHjXAeEkrrRCah85b9rWtgETEfTNR 2ncCC5ROfUBc.VYdUmm4vyd0ld3tFAHKCEpmSwwXLgspuhgVVBXtlEEFUuaLDzllsNZo2oHxI5Ff .guVthCAvqYq2DLQThiaIlPd_rTWz3wODUN4BUsaex7UcmV8EfxorSE2Fk07fIfH_tyVTfdVcLg- - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Fri, 8 Apr 2022 05:49:29 +0000 Received: by hermes--canary-production-sg3-65d7bd97b5-5v4hr (VZM Hermes SMTP Server) with ESMTPA ID 45734e126427a47d15033752fe716772; Fri, 08 Apr 2022 05:49:23 +0000 (UTC) From: Po Lu References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> Date: Fri, 08 Apr 2022 13:49:18 +0800 In-Reply-To: (Richard Stallman's message of "Fri, 08 Apr 2022 00:24:00 -0400") Message-ID: <87pmlsw2e9.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20048 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 952 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 (-) Richard Stallman writes: > Concretely, what is this "knob"? Is it a per-process variable? If > so, we could make Emacs set it, with a Lisp function to specify the > value. It's a kernel parameter. It's not per-process, it applies to the entire system. Emacs could set it, but it would typically not have sufficient privileges to do so. > What is the precise definition of "no more memory left"? It's complicated. I think in addition to checking for free pages, Linux also tries to reclaim some cached data, and the inode cache, before determining that there is really no memory left. > The thrashing that I observed did not immediately kill any process. > Rather, it continued for minutes before doing so. So I don't think > there was "no more memory left on the system", because if that had > been the case, Linux would have known it immediately. Yes, the OOM killer typically kicks in before there is really no memory left. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Apr 2022 06:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Po Lu Cc: larsi@gnus.org, mattiase@acm.org, p.stephani2@gmail.com, 54698@debbugs.gnu.org, rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164939862228220 (code B ref 54698); Fri, 08 Apr 2022 06:18:01 +0000 Received: (at 54698) by debbugs.gnu.org; 8 Apr 2022 06:17:02 +0000 Received: from localhost ([127.0.0.1]:33811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nchvV-0007Kg-PI for submit@debbugs.gnu.org; Fri, 08 Apr 2022 02:17:02 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39468) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nchvT-0007KS-Iu for 54698@debbugs.gnu.org; Fri, 08 Apr 2022 02:16:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59432) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nchvN-0004Ut-Rm; Fri, 08 Apr 2022 02:16:50 -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=ZwTiKFNWAn7U+cg2+h4W/n2S9xt6fFdD12AVTkSyTDA=; b=lt8k9YkylnEv 0DuwYzeYM+RvDtPrlfW7/+UDTakabT+w64EkB1cICTieygP/4k6KyLgdocGV6h2fRvE2UlRkubc/W UUFM9Vep6rm2PXY61QG4mIqMKmPVyrAvpTbQO9H86tlWYTkMtmNNF4tukF3OXK3ji3X1enngJM6iy yo+c2QzaBllGO9DUN4et0sHBaHMxD1XnGpruRHevtxky7P+jeqcJh7vfXcOM2uU/x+03BshnQGZG8 sqBJHjpUy0SYMhWuLVzigILKu6WC1ktymMJEz+GK+Phl6p2kclg7jVYky+VRrp5vrbczBcGZnR9ja bMDjapf3VLF7YJD+kbZUCQ==; Received: from [87.69.77.57] (port=3873 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nchvC-00046Z-TY; Fri, 08 Apr 2022 02:16:46 -0400 Date: Fri, 08 Apr 2022 09:16:45 +0300 Message-Id: <83bkxcaylu.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87pmlsw2e9.fsf@yahoo.com> (message from Po Lu on Fri, 08 Apr 2022 13:49:18 +0800) References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> <87pmlsw2e9.fsf@yahoo.com> 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: Po Lu > Cc: eliz@gnu.org, p.stephani2@gmail.com, mattiase@acm.org, > larsi@gnus.org, 54698@debbugs.gnu.org > Date: Fri, 08 Apr 2022 13:49:18 +0800 > > Richard Stallman writes: > > > Concretely, what is this "knob"? Is it a per-process variable? If > > so, we could make Emacs set it, with a Lisp function to specify the > > value. > > It's a kernel parameter. AFAIK, it can be set by editing a file. Details are here: https://www.digitalocean.com/community/questions/how-can-i-disable-overcommit_memory https://serverfault.com/questions/485798/cent-os-how-do-i-turn-off-or-reduce-memory-overcommitment-and-is-it-safe-to-do From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Apr 2022 07:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: larsi@gnus.org, mattiase@acm.org, p.stephani2@gmail.com, 54698@debbugs.gnu.org, rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.16494036873488 (code B ref 54698); Fri, 08 Apr 2022 07:42:02 +0000 Received: (at 54698) by debbugs.gnu.org; 8 Apr 2022 07:41:27 +0000 Received: from localhost ([127.0.0.1]:33843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncjFH-0000uA-0A for submit@debbugs.gnu.org; Fri, 08 Apr 2022 03:41:27 -0400 Received: from sonic305-20.consmr.mail.ne1.yahoo.com ([66.163.185.146]:43395) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncjFD-0000tw-Ky for 54698@debbugs.gnu.org; Fri, 08 Apr 2022 03:41:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649403678; bh=i9TYK+Y0IwINIZvpKsA0RdGSzS5DyiLyp6TIYcyic90=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=GBgY9VzUtvUWaBWRTRaQYX7iWbcHFfhZ2AN6P/HoQ/kSK6vgvNiuwDBwsGV+HzoOxjSbe+jwUMcxeimi+UzYbZOZJCffI/hzMx1oxwkdX/xDMyfjUALA+LmOYaSovRVqtbQU6wCdlqh6oZc5CuY8uj3iaQlX0uheiPaj6h17KQbyg468thSInk9Jlw4T1OD/MdWoNbgvOcaDPCWzlYjVWnaxtIC83CpSayxcBy/RyQ1xJSh5gyaCd1DEdMXPP2Qn7i0O7I2E/rezDcHDzpF+RSivyltXzqeA2sSmDfHFMGuzaMNw9O25Birz9uzQamDwFQgOiQqbNriBTbgDe8U3Mw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649403678; bh=dbGYEvSjFSY2oDVuxfw4fZ/x3aGoS3IPap/eqxUFEFP=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=bmQEp3PeCgfWDUeesnk22fIpqQguRxS7rfnIVcMqng6RnZYZe7mOFMqETDBFnpPrn24DIpHqtCwxV38yTmwMoNAqoFxdTmLIdft7x0MyW+6FHELR66eEibJLs5HsbVxKa3pazycQ1YWhqr/86J2/q8Cwdx3yhp0R3j8xyi+dvl38dhametwe8L4QChG3JxiF5XJGIjD+EfjSdVnBqOwyAycyk/5pUMvHZKM5WZGl2CJCVZHpc5lB7qPML6Ng5Gob6r73kCxuNiDrKKDGa23Go34wvfHGF/uPhyaTv04pf1IYgSSlp3t7ucvtBRDBmlTP+C4yr40qK3qjDeIefLc1qw== X-YMail-OSG: XRO8j0oVM1khe3mruJLVGfwjSusCWIZGI_6FCgk.HDQij8Flqxl7oQXp2C0eLDJ JZuM_chVhpFxqRwzCxikveudQADFHvDEm3cKWPA9j3ed1JJHIyeWR5.85ATEIue7cd1m2iAVnrc1 g16zhZXtYHBCkjiK61QEHbORsqcHP3oh_4jUvf7cf8lq1b_kh9xaOR8vWH7TpMS1XRxxxYu9qN8i XiBwGMvMwJpel3PRnL2Y.kTds3G4e2BQsW5kPgLlA07ZtwNfZzg3_NagRPaZJx87zJsCvP.7__Me yj2P.kNtuoOIX6fBIEO3.sUpKTBVsS79MqddM4nX1uy6BnyOuFNffsLs.g2MCTkrjMVyDTkI12Ac ELcWzWCL3bH50jm9QoIevIU9Vf9cB1LZYYwRd4IX49qhAyUs8ClLN6lmyxG2x3u5uzEpi1vgTXcI C3knieKhTMMf.m97CXlU0zv1YLshNSnMSSTvaFJ0i4_iQ75ztzdgrHJKBZ64RFBwVRCCFADHUNs7 ZVQO4hER1h0QzEozoYC7EYAfDuL8M5NNUC4hyaLIK6Pvd8wEHKlox7byZ8tC6prjYjQRgxEGheHu w6bi.sJZTyfNY2hiz9zYPJqxCTzMv7vPIyUuR.6I9Ec7SPmTqKIcJ8F2LZeGlJPEDlfuCysXLwDv b04pJi1sRl.oGMC1qad39Y4ygvDIgmM8CHk9g77Wrrf6ogGMiBzWL.2Mz6mFwYMxXKb.Nv9RIVCs HWlX0XSp6GzuB1PRS_onhvcQKEV7VZoE0nAIP1hqQmJ1Xl96CDf95qO.LhFlOJiSSJFzUGyUQiHT NZKsjzTQvo0nwJ.XmV67bLJpAIOsbcYAPRN.KPyxuZKjYXPNkdR9IBlmhpeNCefBp53.wnYNJWdC J56WFGEqLl8RLDnD3Fc5mj0RaWHQU4jhXjgOhHiE9sMS7UbvCTlZgYUohjCCtI18fCuhqN8qn6F5 j0.YQyGlUy37Moh1Y0fsYMFGqmdRtGIt1gD64Z5iL072BtNj0i3IfHdFqJTXmEViRLi_LVhz5LUS cBRSLij2FpAKiHxKb45lhCEzU8a14Ds3Pu0c3xPp8YTH_o3EKmk43lrXeeC67QKzR2cmQSjwF20M WJjcpoYSE35mwpD0OiFb1.V68A.aJRkipCap90Iyy7GvJibida6t32y0Gqfi.IKbjNxOrXtBb6vZ 1oQShemUW9mIrdhqFIpo92RvxQr28DowTBjE3aDl8UdZqzJVqnjjfsJWOfKGVnde0VIx3q.7czsE 5ncUKVF_zJrfedrsy39L8.QtBY2GH1zy_zQ8Qi8.rJ5nmiRWXX5igNMFq7JU7RlC4pDfB6GeXjay 70zGEvTAhwG_xv4FGp4I_S5MSq8U4GrJkWi3A0Il728h4gOPt2RCQL.3u4eHkJMGj8gowq.7j_Qf mM8hX3LTV4mBDGvc3x_3bhRMhZTqgcEq12fbwWz95m.XgDazmHE5J_cm0rvgzx1T6Q6dE8ll_owN CMzkdDKyV_MvAF_k0SVxJpxiOMs5BOAPzbpXCTpSDQF.z_1AKeStXkns8b6jWPikd5TgQTKCIdWh xz2NG1rcRMvTM.8o0u2B0whh_HRDLAflJOfA0_ydJrw937chcOESpAlt7MFAvadKa69DCw27Ez8K dJNvcneiSM2mqWvLtHWqJPsTJs08mzkxbs5Ytc8LRFa8S7sg.4BG7aUbMNnP0damgYZaS2DwAbO7 WYRrDDO6ZAEaUi6ega8OOy763ikXufM0_95lHmUQ9PVrk_YK9id7WB8fCiZxELq5NHKSCqNCgyZf KVQ4ChjDCgMMUT4zxyP3x2yY08zEhtmjKqErrmLhJzeyJbXU9BX_82tAhB4LUJblI.fLheWUa4gF fUF8bihDdmi.YNvIsUBo8JkXIvCSLbqN.jz252pZb4GzkrwP4_rFMK8MStZqWjHiO0ebRt6u6QXk DnbWe3Q4duyr3OGufeKfsvaeioxwF3UInUmvF7FKsHpP.LwxFsQh8vvmJjt43drpleiGInzMoJYK MbJCZbdjPVOjP2n7ULZxgSuuXcVUYo1J62xXrew8ZUdHhBLfCo9OCfLH99YGlau3ZydC_EMIXHsa IcyUGJjn_9AYLFIGJ9tEcxtYarNDeztnZhwqQnwPiFMWYVX4DhhugzVp8yEDFAtffKoQakYkCZAI mv4MrkJDrkjxxv0nREuRhld81ez2P9tSD5wnXtX4ouFD2ujNMvYzOJyW1KmrxxaLoNCqw9HqXoaC OVwgIJfBjI.mP55O.yEZCIOeqE.DGDgzapwtrJoQ8kqYUqCDcdFrwuALJswvSTi8WSoRWcJ3hbEU - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Fri, 8 Apr 2022 07:41:18 +0000 Received: by hermes--canary-production-sg3-65d7bd97b5-stp77 (VZM Hermes SMTP Server) with ESMTPA ID cc3c3cfa69277bb2951ab9d0db165e94; Fri, 08 Apr 2022 07:41:12 +0000 (UTC) From: Po Lu References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> <87pmlsw2e9.fsf@yahoo.com> <83bkxcaylu.fsf@gnu.org> Date: Fri, 08 Apr 2022 15:41:07 +0800 In-Reply-To: <83bkxcaylu.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 08 Apr 2022 09:16:45 +0300") Message-ID: <87lewguing.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20048 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 971 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 (-) Eli Zaretskii writes: > AFAIK, it can be set by editing a file. Details are here: > > https://www.digitalocean.com/community/questions/how-can-i-disable-overcommit_memory > https://serverfault.com/questions/485798/cent-os-how-do-i-turn-off-or-reduce-memory-overcommitment-and-is-it-safe-to-do Yes, but typically you have to be root to write to that file. How about adding this in the Memory Full node in the Emacs manual? On GNU/Linux systems, the system does not normally report running out of memory to Emacs, and can instead randomly kill processes when they run out of memory. We recommend that you turn this behavior off, so that Emacs can respond correctly when it runs out of memory, by becoming the super user, editing the file @code{/etc/sysctl.conf} to contain the following lines, and then running the command @code{sysctl -p} as the super user: @indentedblock vm.overcommit_memory=2 vm.overcommit_ratio=0 @end indentedblock Thanks. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Apr 2022 11:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Po Lu Cc: larsi@gnus.org, mattiase@acm.org, p.stephani2@gmail.com, 54698@debbugs.gnu.org, rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164941652932579 (code B ref 54698); Fri, 08 Apr 2022 11:16:02 +0000 Received: (at 54698) by debbugs.gnu.org; 8 Apr 2022 11:15:29 +0000 Received: from localhost ([127.0.0.1]:34035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncmaK-0008TL-Q9 for submit@debbugs.gnu.org; Fri, 08 Apr 2022 07:15:29 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncmaI-0008T7-Kr for 54698@debbugs.gnu.org; Fri, 08 Apr 2022 07:15:23 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50558) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncmaD-0003Fk-3Z; Fri, 08 Apr 2022 07:15:17 -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=63PGYYM6WUxSwDlnpAjkm/bm9I6+ixxllyloPuxmDu0=; b=cshbDnxdX2HK uHiUyUT3EQEqn8Jc/qjljh09c9LjjkrLn5xY5Wtz0hJAST8EhjdzRBKwF8238LktLJLR8/gzB65AQ bUTvDbSUUPe4+IuS/q8QZYr+emQbAb5shsKMzL7xjPKHFc2ie8CnB4ZyU2YTgyJShfy2E/QeVUPDC TV+qIcTzhIYkdCyaY8VgXR2UubzkJXz+NJlRBU/w9VLq+mNwxXhDL3Fp7avKNSPMys0nGEcJ/RMdy iiUyo2quXBfU/FHEMUkrOCuUFqgV7z9zp/18Ui85vk3wvnl+kBCz7z8UNFzKN66/9sPIrHLQ6IjVO swqzIsMcnDo8jQ0PdrfLcA==; Received: from [87.69.77.57] (port=2857 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncmZz-000844-Mv; Fri, 08 Apr 2022 07:15:08 -0400 Date: Fri, 08 Apr 2022 14:15:15 +0300 Message-Id: <83wnfzaksc.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87lewguing.fsf@yahoo.com> (message from Po Lu on Fri, 08 Apr 2022 15:41:07 +0800) References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> <87pmlsw2e9.fsf@yahoo.com> <83bkxcaylu.fsf@gnu.org> <87lewguing.fsf@yahoo.com> 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: Po Lu > Cc: rms@gnu.org, p.stephani2@gmail.com, mattiase@acm.org, larsi@gnus.org, > 54698@debbugs.gnu.org > Date: Fri, 08 Apr 2022 15:41:07 +0800 > > Eli Zaretskii writes: > > > AFAIK, it can be set by editing a file. Details are here: > > > > https://www.digitalocean.com/community/questions/how-can-i-disable-overcommit_memory > > https://serverfault.com/questions/485798/cent-os-how-do-i-turn-off-or-reduce-memory-overcommitment-and-is-it-safe-to-do > > Yes, but typically you have to be root to write to that file. I'm sure RMS is root, or can become one, on his system. If you are talking about Emacs doing that on its own, then I don''t think this is a good idea regardless of privileges, since it isn't an application's business to change a system-wide setting that affects the entire OS. > How about adding this in the Memory Full node in the Emacs manual? I already said I thought we should do that. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Apr 2022 11:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: larsi@gnus.org, mattiase@acm.org, p.stephani2@gmail.com, 54698@debbugs.gnu.org, rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164941755810219 (code B ref 54698); Fri, 08 Apr 2022 11:33:01 +0000 Received: (at 54698) by debbugs.gnu.org; 8 Apr 2022 11:32:38 +0000 Received: from localhost ([127.0.0.1]:34053 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncmr0-0002el-5s for submit@debbugs.gnu.org; Fri, 08 Apr 2022 07:32:38 -0400 Received: from sonic312-23.consmr.mail.ne1.yahoo.com ([66.163.191.204]:46577) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncmqx-0002eV-So for 54698@debbugs.gnu.org; Fri, 08 Apr 2022 07:32:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649417550; bh=obltxKuJiR3oyxjKMjVzNwvA5ENoafn39mhvQ7QyuFc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=rTF8SN52I2o9xCwm33VdEvccGb3XrjCjYaqKSRLiCxXF6LPH535MjwPm/bKiYW6FMQMHQHNxA4RXSk+KUWkNioZvQE6cq+f8Uc18dTUYhcbg+Ucfy5+T/puGmRL4iRklQLbqTqf4xYwtjt9YXJgFDmt+VKvhQq27ZxQlsg+mwWkSLDsCdv6UIO4/edtf9eerGt3CiogXeiD6bgRsyW8wJYYsymTm/iXX9ZDdqR29f78/2gKctJos1eqhFVdNKIHvj28YECaQ57lRKnt5kiM22tBWefClu4a8PzoDHYW4WGxgMsUpbqTFl2tjIywRcz4Q7XApsPMfhdlARtLdm9yCHg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649417550; bh=NO9pDH5wdO6u3RRyUaRENFNmBPrSr1cD01KMQGoADMN=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=G+PN+uVNQ+rlzz4Pm7jcHeemGslnZ4tCJLj2MNstIx2RX/el2Sb/aEvLYa4SMRTrWtTPscgbxS9bnNb120hI5NgE/bCDrvkxgJKiBHSjVtMhd+0EWMpKLoLWDNnLrbA8SOBvVvVBMUuKFULINLkw+hkiQPsogMqow9+2BoMOED3s8jqGJPB2c2rzzd7b8KKlur2iOIW4Wo9W7LR3tTLMgofoktVgg9t8QKJp4wuyroDEcU+fucHqOgW0/fC5EG8vk6IbazNq/6WLuc0dSiyUqTX72cNIoTy/3M/EjNx6WVKbRqC5XAF5Ikcty55AmXfcN9onOJOXokpLIQ0J/BN8sw== X-YMail-OSG: grr5ZSoVM1kqXyeeZot_WzO5R1Ji68gzhoQpsxc67vc4VBAbUWPHBiIsEEQXW0. XKSqDzOgIx.t9.8b3sh3.gkBDe0VfeWLO8bc11y8N2dNy1ROeoXXBl8BEGQffLkrqaQkM0ojGgy3 dAuM5ruFpygYP5MBLeMj6oy1_bIsqFcK3c2nmRaa2CLIZ4vRxZxCi02d3fdlMbC05oCbQsmoyWtp gvG4zCaX7UXv04jF3VVWrSW95kjAgxaCoAgyihaXwTwPzB3UM2RatL1Xlie3mrEGL9h0_XiBkN6_ i_gTWXS_0YoEs4brS2gOm7IvGn_yGFLdSPsBRxDr7zv1MNtW1ME0.lICTUiOFhIh2pxaarT1xtxZ EkYoBkto88IWwNhx9wOlfeyy1IVNtT50Qq8vP9FD1zBghqyBuZRs86xtAsprlWSNWlkaV0u2Tmcs XQmIFxDkkoir_PXc3ffGtzSMotZM_Fsal9K6Kn_C1GE0osEWjfTozmQUgv9KB.W_EJzyFRzIapFu CwqhbV4tCusDdmSl06hF4WhI.sLPbL3XXQQ4rbKqhVtysnC1zhHdFxq.z1kgJFkO0DfMfY4qEW0a .Cisr3zi1vod9ZMiyaRZfxWU0GbfSWOuJflWx4CwMerMdEO3TPM0QDKPBhY0zts1wqbz5QcVflV5 P9z6XyYO2qVYLlhw8jGyLBjE05gX0Pn8RphHD4hGAeYvxc7wI6LLu4TVsqgZyZcyBMyH4LISp1bn QIWpAT.aaU1lqNAmIYx6GVLS7ft1idCHkZ9cZNODT.6MY1drIPQ2zSK2PIJvzVIqah8x2m8HuYp1 azfK68A8n2WnowBkq5T7NDqeijzF9UENVHp2.uD47LZ1nIkGr9MC4HUlR_rXd8P8Xi1z6lVgnp6R v6kJY2fgyi6I2GZSxPHw89M0RXf53khPiQeXe0vOQk4ZKHuAWpExaMOzVixSo3elNkE51LeiieNK SUGMlPgyiz7g64ly9Ft4_k6w7s9IktrpBau.jhyIwI6oQUnTUCWzhqT75cpqDuenorNK9gsWoiZV hH.DsKh1lJAKKOrniQFnIZRd.0h3wvGBfTe0m1SxtYLoC4AU7BvFST79hJVRNmPUWHWCUn564QU_ iOrTtmKCC8erK0CUW0JOYlCGkGveBHfPRFgyHJtJmKULP2lGbwmHTkKGwAeZUThLT2lKuyuKe9cV oO4U7YeSDpKIJdS3V.n2rDYoc1TVSY9FXvRoEO7VL9bL45wb7lPlVq6KCeNz9vXPkTs3IFCAZXe9 FN8isXhTuXKBxCA5wdPICj6_9Vb6IUy98J_z.Z1e5nhtffzIV86YdDdVEffuGdZvO3sOBu5lN.yJ QWowxvgsE_BJqZG6XlakGMMgTy1KtEGrVLcbMqNuI38x1m.b7zqpr2pTKA6HOWchU9K71_LsH2c7 nFrdBh_fy73wGBm1_HGvpTjxfajIy5mrzfr9gyQq_GPnvzAgXRap3hOMQivetM9V7ddsEVoiBVk9 x4WcMfsJVtH7dXYEeLi2yjCVp0ilnBmIfUDPAhVdrMhb2.Yt_Apa4uKHwVUe_TS1ShMiuW9O6aLZ w510VhNxk_qfxCzNAjRV27D1tbpXh3BP8Syg2HRaFLzlIOLTL1DpR9BkWybNYxfpW26iEDJ44WqV dHqOD4SfavC0BTlnRbf.bK_JsgPR4Gnyt4pdqMYP6uI98Ej7n4EQy4nq6iRtWfci0CH_ezvg8BIW .EmE8mOKgqFpbtlyJI.OMKPjHYr3sCIhkYvkZDnjB0kae1JNtF3ZP2ppOSc6YX8ByJjU6Cc4HBkC Qty.IfpZygIE3qDwuFp_RO47GV7b1Y0zg9eXWbpNH7ZJSWNJFMkUvmABC8tq34QoqubuinNCw6RR q.7gjlh.TpabMcZ.AaJlFNnHdUIKXqTw561cJNb5EGCif2nEHi00.uLk2G1wmfc3o.dPhvO0f3ZZ L6vjXp9PRY2F8Bmv0Mdfi5OhQlDDRJeSNHEUA4Xs.TX5DykkZTQis_qqNCj0KSkxswP0YI.cnhfI srQxAxKy6x4Q39a3YvCn2s7m3yjpCqwYbFsnKNBxHjV2MNgCSEmP0KxKAxScg15Xsm0ydYr4jpfx qyGQNBCJPSQ_JsFw8QuOrsL_jlGWccm.FlRpK9WkNneSujhdMLN2FQpBq.YAII5HNGeWjp6HhV9M g7AGrcypFcBxKY1FvIfl.Ofa8UH1MaorA3V2JsUEELg6g9gC2aDY1VAQ80kQHPTf7NHMEbx1laRW sjA70skTQOX11yVLgra11qxi841O853MOKdnlvDdGl0H6mGOJGSEGuFOTGthJvP_5ZHUAmmJZjvj qVQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Fri, 8 Apr 2022 11:32:30 +0000 Received: by hermes--canary-production-sg3-65d7bd97b5-gqv44 (VZM Hermes SMTP Server) with ESMTPA ID 5dbe29e1fc3b0baa7fc45b6aaa5ea2c0; Fri, 08 Apr 2022 11:32:27 +0000 (UTC) From: Po Lu References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> <87pmlsw2e9.fsf@yahoo.com> <83bkxcaylu.fsf@gnu.org> <87lewguing.fsf@yahoo.com> <83wnfzaksc.fsf@gnu.org> Date: Fri, 08 Apr 2022 19:32:22 +0800 In-Reply-To: <83wnfzaksc.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 08 Apr 2022 14:15:15 +0300") Message-ID: <87ilrju7y1.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20048 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 522 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 (-) Eli Zaretskii writes: > I'm sure RMS is root, or can become one, on his system. > > If you are talking about Emacs doing that on its own, then I don''t > think this is a good idea regardless of privileges, since it isn't an > application's business to change a system-wide setting that affects > the entire OS. Yeah, we were discussing having Emacs do that by itself. >> How about adding this in the Memory Full node in the Emacs manual? > > I already said I thought we should do that. Thanks, will do. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Apr 2022 11:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Po Lu Cc: p.stephani2@gmail.com, mattiase@acm.org, Eli Zaretskii , 54698@debbugs.gnu.org, rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164941892812788 (code B ref 54698); Fri, 08 Apr 2022 11:56:02 +0000 Received: (at 54698) by debbugs.gnu.org; 8 Apr 2022 11:55:28 +0000 Received: from localhost ([127.0.0.1]:34063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncnD6-0003KB-C6 for submit@debbugs.gnu.org; Fri, 08 Apr 2022 07:55:28 -0400 Received: from quimby.gnus.org ([95.216.78.240]:59394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncnD3-0003Jv-R9 for 54698@debbugs.gnu.org; Fri, 08 Apr 2022 07:55:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References: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=FVFR3X6lKHWN+8d+0FZ3xjCMigAfzqc1wqwFfpsF0TM=; b=XXMXhv45WApdcRVuetEGxk9om+ A3RNygqzN7lVEjLoVWv0Nk7vXUpSe7Sy20wkn1PKw0XPd2DBTZJWKsHtokSWDsVQudbmKVU/H6dJE N1hUw7JMCJxWvUNVCzYF9bZfrCcCyPqwA5AlJXAN3xSc7cP7s3Aj9Wub9/qIT5FzwqJw=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ncnCu-0002Hj-FM; Fri, 08 Apr 2022 13:55:18 +0200 From: Lars Ingebrigtsen References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> <87pmlsw2e9.fsf@yahoo.com> <83bkxcaylu.fsf@gnu.org> <87lewguing.fsf@yahoo.com> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEX8/PzR0NCgn5+/ v78dGxxdXFyAfn////+LArNgAAAAAWJLR0QHFmGI6wAAAAlwSFlzAAAcIAAAHCABzQ+bngAAAAd0 SU1FB+YECAs2Dl4Mj4MAAAFuSURBVDjLrZM/b4MwEMXPDjC7EtmtNMrsIdn5c85sCdgZQr//R+g7 ArFV0qZDTkIy/j3fHecH0ftCHbYxgx1vw7wEn2c8++7SXe4vD2A1N1TazOYiLyOoFVvFrnQZXig5 0dBEGaQQs6djUpwM9UxHiPmKVQSWCkgniHE6BQFbDQ3Y45bS73BI0pCIpZG0OOXYETEHnQCrwo6r nYh5LCLwlLfUB91KKpNFEKj3dA6Fpz130tkKDNI6mYelD1JxiLWIgsY80ISsV+AHrP0woIA/TP+4 D2h/hnlpiK9NTPMh9aSMnU/8BSxG5HTQlZZ55RFUSvwQ8lCIKgG4ixGWyMbFKLEGXXAnmNhilAiw 6hOjRFARyt6N4umWgJpKka5GicChxBVGud2NknRldGqUBxjhkb5VMxCjrAB+QIFaSUPs8ggq6TXD PIweOulsBeKHoDGPsEx7AY1kqJWdc6jj87GLKRbw+0WdNn/66bUf3hDfQHOh1QdCM3UAAAAldEVY dGRhdGU6Y3JlYXRlADIwMjItMDQtMDhUMTE6NTQ6MTQrMDA6MDC4dy2ZAAAAJXRFWHRkYXRlOm1v ZGlmeQAyMDIyLTA0LTA4VDExOjU0OjE0KzAwOjAwySqVJQAAAABJRU5ErkJggg== X-Now-Playing: Xiu Xiu's _Joey's Song Kid 606 Remixes_: "Joey's Song (Club remix by Miffy)" Date: Fri, 08 Apr 2022 13:55:10 +0200 In-Reply-To: <87lewguing.fsf@yahoo.com> (Po Lu's message of "Fri, 08 Apr 2022 15:41:07 +0800") Message-ID: <87h773aixt.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Po Lu writes: > On GNU/Linux systems, the system does not normally report running out of > memory to Emacs, and can instead randomly kill processes when they run > out of memory. We recommend that you turn this beh [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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 (---) Po Lu writes: > On GNU/Linux systems, the system does not normally report running out of > memory to Emacs, and can instead randomly kill processes when they run > out of memory. We recommend that you turn this behavior off, so that > Emacs can respond correctly when it runs out of memory, by becoming the > super user, editing the file @code{/etc/sysctl.conf} to contain the > following lines, and then running the command @code{sysctl -p} as the > super user: I don't think we should recommend doing this. It has serious deleterious effects on the operating system, because many programs written for GNU/Linux depends on the current behaviour (where malloc-ing basically never ever fails). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Apr 2022 11:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Lars Ingebrigtsen Cc: p.stephani2@gmail.com, mattiase@acm.org, Eli Zaretskii , 54698@debbugs.gnu.org, rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164941914013094 (code B ref 54698); Fri, 08 Apr 2022 11:59:01 +0000 Received: (at 54698) by debbugs.gnu.org; 8 Apr 2022 11:59:00 +0000 Received: from localhost ([127.0.0.1]:34068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncnGV-0003P8-TS for submit@debbugs.gnu.org; Fri, 08 Apr 2022 07:59:00 -0400 Received: from sonic308-56.consmr.mail.ne1.yahoo.com ([66.163.187.31]:43558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncnGU-0003Ou-ET for 54698@debbugs.gnu.org; Fri, 08 Apr 2022 07:58:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649419133; bh=HelBaMPjIXb3mcQ0hGWc6gjMu0a+8r12/NLF3QXBVao=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=SSbZcExWTaJve5fHJcjZUa2AbwCd1NLM6tMx0pWZG27FpOAxbpqVsThXA1WDxdZw0qRT5MhavczylY2cgkmZI2q+m1avlGkONHKx1bKrwICGbNSFCkakeB9XFdbYZW02iwKOycm/q8J9Lyno3dUm7FVgdQWLFRVP5eSdDhJojmChuRPdolrd6ENXI6mGEh6MjFMq/XrR6ZQfD4V4h0+Lp/KCyHsFO6vubmUs6i5BtlZMbBhi4qWjjCbmCOUIwIq0SIJZSq3X6UnyEVDO5YGcsf5vfGXyGSLZb5Q5ered/8ZeEOT+iUnmmdh9GBGzNhcNaERw1W+LErYUP6l4B2KXbg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649419133; bh=WDZXRRzs5ehqTx2x+T603i/wC/bCD9xcdiHiVR/YGUx=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=GOiEG2ya+ckBPhh6kBTiYaNxvSh+TnZS0qGyAaYQltfjrA0JTrx+i58C8yMl3K2ETNBjl9bOBzqN2HI07CFbG5cE+QuTPd9B1RtMpNqqret7f3IrKC0GFgkmCmKQcAPwKiyANNwUk+c/SaVzIwbfunnAukUIk6ajIOK9Ur4GaoOLBVRGMlSF+M0/z/LBtuQUgSFnVt4QAcpeQSAkiWvPBp+Y2J6OjpafnKRZhL9tdnlfn4JXWHvCdlBNtlo0CNgmnOOCALhMEDAS12168EZUGsGgC5sa4UWHvI+FSAqZclwd8v6L3/Y3LC39/anA3RjLI8cHt3NVvudDLNveMZ+aeA== X-YMail-OSG: 9So5Nu8VM1kebkIXwtvV7yFXn.rY64fyAl9Zn9.WOpuX.bzd08JbqM0DaBan7ps LbvSrLws82HoX3AaTL3Rou.49Ust2MzuHTZgjpXgjW9RDXcPsYkFdA9VE1ArO950NPVXRMzZQmV7 P_WTa0h1b704zpJ8g6lhZSO53Qe2pWfQNozEo92BBxQ2fPVJ5myea7KZ7JJZdHtdpbaCoEkb6ABu hyuInJkwffHe7sdhVXKEWp75WrELNJCTScP736tc6i.HK7wx4PJt5XZh5vNLyO4QkNMgQ2RrG9ht t2CLz81NvcXsJJbOnKOQH3ly0S_CxSP3ZMOpgJIjy6cDOKUnfZjn2QGMTmjWGZ3E6w9b__q0_sqW oWQ3vrQNag.UP4S9yC7Lx2sprxjGIy9sllVlnu3S7s5u1lGJ0_GduK3uDbcNDvU5CG3IwebeD.bW J..6XPjxPcFlToBUW3Zp0_xwMow7ijH9ARwRUA1prOHA0KcRZOjWk5PnxXWiywUnUxGufBgNkNgR BqSpPsj_po9hesgkhCXwjz1PBZDP4x5_aZLFzeqCC1ghAJ5JvNCK7ENzFOmFoiBTmCKLUEkn6KSg fHzpfk50MShXcmgzXlz6mKPFGq_AAtZG0F7KEVRoVDmUVY.QN4VKEQmsYksz.Lgb0Wy71E6c8b2W OWHwJKH0JELw5BYa_RaYfSjDLITP_EnuuijxkQib6J.smdsNef12GDWXYoO7d.hGjtIhSIuahqVU 4aUOCgOnhzFNMyRFQoU9CUgzH40pZs2TD4MBtOcAcdrw69oKFJOmUhIjbS_5apuzCsNOodCRqgzM BO1mydWg11TsJZvLanpKmb4G0CWSDlDqf5f5jCZnJMKFsc.anFSye4AuBWraomgi4xNxdAE8x.tY Vs56Wag2AunDm.oO32onB9xjP3dNUBApaeXt1SIOjrmp6s7OjX21P09VDj09o8JMjisRJNOPmMK4 3Yl7u0pDFN_fcZB.LJMvO5XTiWSp4dCvqXSV2V8USESI4lpufr.dEn0nPwh7TaWLNRr4GrJ8EpCR WmzjxStO4Nc9ofeHnkF1Bi1hLbS8259hZv4AA8TNM1PFXLcA.926iNymLHcqh8NSoZis16sdLLAB 1_NpqTkOmh3iWDzQ_NXU0FLOqCaF0syE59T1aJrRUsmx3Ue8W3hO.ekwGK95nvde63F.j4WGI3iB k8LB7Vvj1SnqQPaREO_2X_6bKug1n8qK5xl4cmD_oC4ZJhzu1gJyFqe07SY1lfGLa9_Ad3PfBGyw 4cl.uaRvaPx7bdEAGG96Rc7_hUpzI3cr6CBh4W_TvRLu8XZyYjsHi_3r89XvuUV8bi1xyLza7oQe 2ocA7dLyQ.rJnIx0UqQ9hzCcUXSACaSeej2ldfhueqSgiZkRQ0J_U5Ue7uxK3huLRbE2BqmnQG1T yoON5xorbRNSIuelYLzPOH1lGH8LbfCZpPayl3qSEsQ5RoGw7juZJZi0WWeAgY9WczYxBWwE.m4l YqnqFrV.AWnhAzPMh2uEX9M16H5ThjvU0NeezzvufNjlvdLhjv7ic9jHrmcsiaGazhmg4IQk808J D9qp7JSBCuAkcalNoHgG2bRmkdEDpS8ePgf_6IumGQN1GycYL0sDipkUX3PT0p_G_cK1hZrbbe0J CZLJE6R7M79jRKFMHnjsClEFemrrnnU_ey4ZlNXctBhvRFfIELGckuUhz5hakN28Iyd5WLsz_tMr 2DH5WIPLBJhRGbZfYd5jFlC7tQBLhtVjnzyA8uvU8qGa1B7bYx06ephCAqKWR6_ohe_vpt34j49W p44zdJa_QnTRBTsuJR.Y2A.QXPMOXlhzalqDUCxmpcDKyDhzRIs7wratZjQUtixS5c5lptZlAIyN TU4Hm7mdwoJElrdZz4DHLk1IGBEXUFzZwB40Nso4n6tPFh8lY2J2h5I0EHR_5nOdsEK_sULlZ1qi HXUXiKFLCHw5mI7.TD3Ov2MGC92.2SmG73TblEXcMl5PXUjF8GtU8dNRnl.YSqI3ggnpjf5NJjel DWhIYaTcQSaAaqj5xUi1MUfK09cK3ccKXnliNzHqdufsD71Yko6bJIJp3_6jwWT3_DcLYw2_FMfZ yGXAEm6r962K0.aJT.tUxaPRN7tBXZ53k8IcEhpp4GXhQcuGF5_nmB1sUUpSVREF5Z1qPH_msc0u deo_xR0HzQebjH3C5Gz9Kbis1a.ScXz71DQGOK7.tz1htxzp0yYjD7uSVcxBeVBBMHtklQ3_chy. D4Sodfl0quechPHlLh7B9qdWH_ZPwpkdQd2aDu_k9hxMRjVzSDnZxyCQhhwQa7PESHK38pyWvw1l _hyc- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Fri, 8 Apr 2022 11:58:53 +0000 Received: by hermes--canary-production-sg3-65d7bd97b5-r89m2 (VZM Hermes SMTP Server) with ESMTPA ID d2eb74c29aaf453b390fb6b3bd324cfb; Fri, 08 Apr 2022 11:58:49 +0000 (UTC) From: Po Lu References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> <87pmlsw2e9.fsf@yahoo.com> <83bkxcaylu.fsf@gnu.org> <87lewguing.fsf@yahoo.com> <87h773aixt.fsf@gnus.org> Date: Fri, 08 Apr 2022 19:58:44 +0800 In-Reply-To: <87h773aixt.fsf@gnus.org> (Lars Ingebrigtsen's message of "Fri, 08 Apr 2022 13:55:10 +0200") Message-ID: <87bkxbu6q3.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20048 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 485 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 (-) Lars Ingebrigtsen writes: > I don't think we should recommend doing this. It has serious > deleterious effects on the operating system, because many programs > written for GNU/Linux depends on the current behaviour (where malloc-ing > basically never ever fails). They will either get killed by the out-of-memory killer when overcommit is on, or they will abort (or crash) on failed malloc. IME all except for some special niche programs work with overcommit off. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Apr 2022 12:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Po Lu Cc: p.stephani2@gmail.com, mattiase@acm.org, Eli Zaretskii , 54698@debbugs.gnu.org, rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164941968014063 (code B ref 54698); Fri, 08 Apr 2022 12:08:02 +0000 Received: (at 54698) by debbugs.gnu.org; 8 Apr 2022 12:08:00 +0000 Received: from localhost ([127.0.0.1]:34077 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncnPE-0003el-Eh for submit@debbugs.gnu.org; Fri, 08 Apr 2022 08:08:00 -0400 Received: from quimby.gnus.org ([95.216.78.240]:59586) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncnPA-0003eU-OL for 54698@debbugs.gnu.org; Fri, 08 Apr 2022 08:07:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References: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=OHjFvjyZF/jN6qplNfCDaZMTnNylcHNI7tV5PqBpbX4=; b=L14jqwr4YEDadn3UYFKp2ooupg 2nBMK6Gfstq3iTUsvVtptpBnrsVsrbyL76584DyhjCCy+SkFJ+OtPwhjdEV98rA7BLWxoRLi2vBBg p+kVZK4pJB7QmJ5ICiCTclyIlNAQjZnrCoRezHQhp320CHsTpGHZMZZqs88Vu7gppxdY=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ncnP1-0002S0-0S; Fri, 08 Apr 2022 14:07:49 +0200 From: Lars Ingebrigtsen References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> <87pmlsw2e9.fsf@yahoo.com> <83bkxcaylu.fsf@gnu.org> <87lewguing.fsf@yahoo.com> <87h773aixt.fsf@gnus.org> <87bkxbu6q3.fsf@yahoo.com> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEUwMy1ISTlHTUHH mD3///+qs8CiAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+YECAwFAT+X4acAAAGHSURBVDjLdVMBcsMw CIPtA8A+MJwPrMn//zaJ2LHd29K0TZBBIMsiEpHu3tLDZbsCAYuW4rYDXOkeGf6WgTqi3lq8Z2je QGPC58+aAdCjgUXk687SAvARAix1yQS0aqMtkOmr4j2NtcCBuHUKU68fkJPbSVFFovhQSjWygE4R 2TnQVPImBSr6DUQzlEpOXhTQrU3AMWU0TmFU1DrQ1W0XGsZz1gBaE2A+3KfXlfcYgX6Ug7fj5Noh MjMQ5nXgC74hMl6oLcCrJB7qs1TPOIm7DIDV70pn/T0cfGTASAG6Z4Pv5S3t6g+PS+o1Us++YANy UPj39BU7hezHXujmSMhy6VaoAPQS+ZLYEgThhLjYC4izAuVpN+wFJ1pKfUBSBC6ROXW3T3edpm72 1YRsPtdMYOtxJV+GfT8F8k/G35WUJpmQb4A9BrAJ0D3OAXSu7RpSkl3VsU844guLtqk6SGRJeQB3 2WexSgRAi6/BEr32uTtfaNzRHT1t3nXxmIZDgo52YcnjquNkv+pjN5L//7WIAAAAJXRFWHRkYXRl OmNyZWF0ZQAyMDIyLTA0LTA4VDEyOjA1OjAwKzAwOjAwo82ipgAAACV0RVh0ZGF0ZTptb2RpZnkA MjAyMi0wNC0wOFQxMjowNTowMCswMDowMNKQGhoAAAAASUVORK5CYII= X-Now-Playing: Throwing Muses's _Purgatory-Paradise_: "Sleepwalking" Date: Fri, 08 Apr 2022 14:07:44 +0200 In-Reply-To: <87bkxbu6q3.fsf@yahoo.com> (Po Lu's message of "Fri, 08 Apr 2022 19:58:44 +0800") Message-ID: <87czhraicv.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Po Lu writes: > They will either get killed by the out-of-memory killer when overcommit > is on, or they will abort (or crash) on failed malloc. IME all except > for some special niche programs work with overcommit [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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 (---) Po Lu writes: > They will either get killed by the out-of-memory killer when overcommit > is on, or they will abort (or crash) on failed malloc. IME all except > for some special niche programs work with overcommit off. Users will see mysterious segfaults that they didn't see before throughout the system. Using the default settings (which, after all, almost everybody does), you can ask the system for virtually infinite amounts of memory, and the system will say "OK", and if you only use a tiny bit of that, everything will be fine. With your recommended settings, programs like that will segfault instead. It's the height of hubris as Emacs developers to recommend OS-wide settings on something like this, and it makes us look like amateurs. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Apr 2022 12:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Lars Ingebrigtsen Cc: luangruo@yahoo.com, mattiase@acm.org, p.stephani2@gmail.com, 54698@debbugs.gnu.org, rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164942005514668 (code B ref 54698); Fri, 08 Apr 2022 12:15:02 +0000 Received: (at 54698) by debbugs.gnu.org; 8 Apr 2022 12:14:15 +0000 Received: from localhost ([127.0.0.1]:34082 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncnVH-0003oW-3Z for submit@debbugs.gnu.org; Fri, 08 Apr 2022 08:14:15 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49250) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncnVG-0003oJ-59 for 54698@debbugs.gnu.org; Fri, 08 Apr 2022 08:14:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58558) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncnVA-00060w-Qk; Fri, 08 Apr 2022 08:14:08 -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=j1+MjzSgQMVQ8IKEKXsGRbaPqnCeLrIrS8nO8mm3WeI=; b=noVDc7D1nii2 jf71T0OXiFVOWFiINuzoW9HhagvdaJO5rDhqjjJS3QQ8IEfptQajwI4je06CX+Tai/Rw9Uf1C9D5y SPG4VuJUKQNq9xVoLSkeUlrkiNor6g7Fx9Oth3Al8PFcxWykJPTnsL8r9WiN0+xWp/11NeZrN/wc+ ujhwQfgqeHfxfZ/j4HCNHhSlMGujL9wqXkPjT25p39g8idF79Lms3RrM08I6P2AyJfXSo6fX2sfYt SITRP4k/ej5yhDRPBdym1Qy4WiiRTWMuexMUCMLSH2PRJEYZRv5ywULyL2HRrnVH6EOxO8nRJQz+8 SUzPtS0iLxVZwJ9tlF1k/w==; Received: from [87.69.77.57] (port=2627 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncnUY-0004ic-Qw; Fri, 08 Apr 2022 08:13:39 -0400 Date: Fri, 08 Apr 2022 15:13:43 +0300 Message-Id: <83tub3ai2w.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87h773aixt.fsf@gnus.org> (message from Lars Ingebrigtsen on Fri, 08 Apr 2022 13:55:10 +0200) References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> <87pmlsw2e9.fsf@yahoo.com> <83bkxcaylu.fsf@gnu.org> <87lewguing.fsf@yahoo.com> <87h773aixt.fsf@gnus.org> 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: Lars Ingebrigtsen > Cc: Eli Zaretskii , rms@gnu.org, p.stephani2@gmail.com, > mattiase@acm.org, 54698@debbugs.gnu.org > Date: Fri, 08 Apr 2022 13:55:10 +0200 > > Po Lu writes: > > > On GNU/Linux systems, the system does not normally report running out of > > memory to Emacs, and can instead randomly kill processes when they run > > out of memory. We recommend that you turn this behavior off, so that > > Emacs can respond correctly when it runs out of memory, by becoming the > > super user, editing the file @code{/etc/sysctl.conf} to contain the > > following lines, and then running the command @code{sysctl -p} as the > > super user: > > I don't think we should recommend doing this. It has serious > deleterious effects on the operating system, because many programs > written for GNU/Linux depends on the current behaviour (where malloc-ing > basically never ever fails). We could explain the advantages and disadvantages, and let users decide. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Apr 2022 12:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Lars Ingebrigtsen Cc: p.stephani2@gmail.com, mattiase@acm.org, Eli Zaretskii , 54698@debbugs.gnu.org, rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164942020414912 (code B ref 54698); Fri, 08 Apr 2022 12:17:01 +0000 Received: (at 54698) by debbugs.gnu.org; 8 Apr 2022 12:16:44 +0000 Received: from localhost ([127.0.0.1]:34088 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncnXg-0003sS-IV for submit@debbugs.gnu.org; Fri, 08 Apr 2022 08:16:44 -0400 Received: from sonic301-31.consmr.mail.ne1.yahoo.com ([66.163.184.200]:44368) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncnXf-0003sG-8r for 54698@debbugs.gnu.org; Fri, 08 Apr 2022 08:16:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649420197; bh=EeqGTYiYujcnU3nmMAgxHwIKz1+0Q0ZOp0EXOAJwo1U=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=IVjjVZw92lISmp9pHIKcta3yJz+U9DPUf9fyBqKyif+A+SGsTgeTxyaor9PYNH+16xa9TvaWG6j4LwhYFsBt/xgU4ES5uFqi454l7XwoksrcLfzke0bcNy2pQ0ny8QGqp9TGDairRQqquhfCXJHVt80tmmTxZn7bnyr2U9y6VC99mj0Hf8z7GleVhWOyy0AG/9p3JCq/9w8GtebK9YPRg1BEdEZrxConoqVM+UKQAhUCbUzhl+5/24S6sOOrZy5q6BuCvVf7wabD0GZaB1kKGq0tJDlFG8n5PBUO6qYkZmyJeU+FMNQViyFdKlWJuTHHYN+Rn41PoFfx3xP+TKQIwQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649420197; bh=Gea3kihChQUiFjaLbjbun1SXgjJHe4cdWgDIPJAqO25=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=d0afOwJ5coaCX3qa/5TFeNiLDjP5cd7MWwLVBJY8I1sM27xYLhCTIsZHDy+d3vmwF3MYXyVKGm0gmf4ELffVYJeCvxy/EqPm3S0g2UMyPSSwfGh4gZSukgz7voCQyp7Oan15WZMOg3HrbaeJIvRv1BEyizkuuLkYKHj/TSpq5DBNavyzmuj1APIoOZVNeoPYRMJzS3Dyd93uYjkFst4iViqANR5FuLK9ug/h37fajWZAz8LRB2wFTe37bDrEGLouNOtlG+FE9f5h67fpGeQkeF6LRh9DV96eyUudVZheshwhfhUE5/lOxMpVSgkdsNDxDg9bgV4MxLhr8e80KW3+0w== X-YMail-OSG: 4toTA.AVM1n45I9JtOpXt9ZjIJf.jaWLkQsTmFqdlNmhhxvAV3m_Nz9zQQwfLLL w28cL8iPAgMKjzL7i7_kyyYsmtwUlNgpQRLAYAWjWz4t96R5z7RiXdMtKt_t.XaILEkkLPTCS.JE gXxRQ3bWSPvM1ez44jKX9QDVnZRVMD3sKtuSCfRfIEY9y_hcMUzHKoUFoasIznm4KuUCB5rjoost 2BzrY_WTAL1K5sPMBFjcwzeKl8h700KvgNclklufh71JIpwIwu_LSfQB_jjAyuGGQBWAJmT9PB00 oOYlsOPsuoCQJCBpujbxw5wnsUp8HfJmsDGE3txD8Aj8f.W7n4OtLZ49uAeI88wxGcQFOnm.NH62 C9mDJX8DgfKI3le3qT9Igxv_QQCq2OnmvxUOdcxuHp5UviVgTlQTea9_ekopmvMzkBaZfRLNrMZI deupMFB5U__e4TQx3xN26cVZeQ_dJNDIMnBZ.EPSNyrClUzqKnFP30wa2if7o0dQ83UQbV4srd45 PCmoCwMBKuJiTtbU4oKHo2jznds1vGW4LN4epYl_qSu8hgr3Xtk6Dc_a0nIDnOSHijxFWH.5jVmZ eRfPYPJP.z_VjrJ3ZGrpNeVdCs0_U7RmD7O5JpI7BoFMnOCYIv5zWgq1fGWxpu62cblJZAbtuGP2 aiE4ZtoxKaoiM0fHP.i8F1o6LycXy0PVkX1PJFYw6VDN8NcBjG76nQDUMaL5SEzKwFLbsxewM_gb .pgXTV_XW9vZwU5dhd16R4HKYd5tqYmVlyeFb1htm0lSYA18z6JtyQkmi3ZWxq4nwt9foPCCSU4Q .1zv0JcnbiQVLFv0rACDX9USuWAv_aqggdOD4R1Yit0Co0v8a2GbW6OtBpdmziBmlPSk4yLnDJrh 5V_K48fNpNlkVrzfpq2iCNFMUW_0XNtH2FR81hejAzWkPxNvv9ySpqmr81UjRbles7gu2PoMJf7S .Fq4q9RvTx0a7_SPRdca2akH_m4QjrNvl9kkHEwu68ql3GaqRyN0CZD9etEHDDqvdZ_G2JQw3OGJ NLQT.3uFiabkIHPA1xxlUsNuPHPag4dTsCISRwKoEqBm5H8VaNmsCxH_XcKLTV5dw0rN4_uTRa_a BYC7EIcuI5RzxdvkiOLxCZmEu3jgWJBF6h3OOLTG49Sr87rXzPos2rDN.Alx.z.D_Ol1M5AZQPcp oIiY8ft6N38Rxa.0TyZd6QqT8MBWyoR_cSnGwfLnYVxwznJcPku4.cKUEQTUiBhIe6zWO53H2Z7k yg1gufN_viUuPO8aVVXuxxOC3qjQDro8kR9MbUP_mUAFVEW93YrufnLgU1JjuxUiN2Gq9Bz8CyBy Uu1BuyK3TbpJfYg1HRvT_Q.7v5Tx_WWSVkHEGOn3l1XqtTS6ATKKtsP6tNB.iPGAAx5bzDe9_VsW EESCm08VJNE9q1yGu2VxQ3XlRF76mJ6ojwt34.ddMON52jJfXfIN2qV1nl7ITl2MjLpN2kFXtOK1 b4jmixPEBj8URaDDQ3Dbz4l5_xkAeXQ9KyhvbG.rfV7SbwYO5.1oCqr7xb8G0J0ZQvzQj2SCAZ9p Wd0Za_X8B0Z12OznU3CSy5b_lF_8hR2doKBc2oboFNiayHF05QdshzdW3fmXBJeA.nhnzwTJelZS 3AX..XchQ7f7n05RRN1a3sYdIJPSrlxAW9YUKKhzQiRR.Hf1lKpiHNyBTiIuQZtNdYt9xCjagq4s LNAGhPZpqaQYpC.53hSwqVNxRelH9.bhDTrVUE5gfxj.caIuf2LQNas0xxFyImmuLmyFmAwEsfuV RCwjHLmyAAVQYEYgnRbOw54VJ6c8Rju34hZHMBJ_iKs9tJx_b._krvekZ.19gQQ3Zhtcl_HTCDEl 5uF2WDSVgz.I8R5s3QpmHfrUGXHylP.WD2livYATvVcFqlbGy9OmKFVIlEJVK4AKblAawaWbzzf5 y4t73_SLW8W0K89O_fhk3P6LDQntqZQ7njZLdP_RHZxeQN0au4P1wq42JjKVWDS5QEUTwcU.NcK5 IrMERsNspiPPRajijou4yUz6X2OXiO8Fh9EAmltgNvfgnYoPa42T6sIb_sV7FYEmfMH5p92.xyd_ 6KwbT4lfoHVJrghU7iVsbsXS98oPSwlZ56eqXeMwSE0YMrKCBIiOFjSelAmsGA7M7gg_qOAhFOLp 8OZhT95H6Z_95gl8ZX2HM.t1mfjsrztl6iqDrNPTw2Sx.kTbMvvi7XHZ.JP3BXiWlLqMCKCbzhFp vdhyuHxgQsyW8S.emaw.fXMjsV9LH5Q_Se9NdFqB1xV8qN2C4mvPs8rTNvPGkWdEfdRcYz_xhSLY i72fq.kE- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Fri, 8 Apr 2022 12:16:37 +0000 Received: by hermes--canary-production-sg3-65d7bd97b5-r89m2 (VZM Hermes SMTP Server) with ESMTPA ID 3b01ba6b95c9c5e9d991ddf3db67e692; Fri, 08 Apr 2022 12:16:33 +0000 (UTC) From: Po Lu References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> <87pmlsw2e9.fsf@yahoo.com> <83bkxcaylu.fsf@gnu.org> <87lewguing.fsf@yahoo.com> <87h773aixt.fsf@gnus.org> <87bkxbu6q3.fsf@yahoo.com> <87czhraicv.fsf@gnus.org> Date: Fri, 08 Apr 2022 20:16:27 +0800 In-Reply-To: <87czhraicv.fsf@gnus.org> (Lars Ingebrigtsen's message of "Fri, 08 Apr 2022 14:07:44 +0200") Message-ID: <87zgkvsrc4.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20048 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1367 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 (-) Lars Ingebrigtsen writes: > Users will see mysterious segfaults that they didn't see before > throughout the system. Using the default settings (which, after all, > almost everybody does), you can ask the system for virtually infinite > amounts of memory, and the system will say "OK", and if you only use a > tiny bit of that, everything will be fine. With the default settings (0), you cannot ask the system for an infinite amount of memory. The kernel will reject deliberate overcommits of memory, but will let programs like Emacs slowly run out of memory until they are killed. There is some guessing involved, and that guessing can become unpredictable, leading to behavior like what Richard saw. > With your recommended settings, programs like that will segfault > instead. Those programs which ask for huge amounts of heap and do not check the return value of malloc will crash anyway under the default kernel setting, which is why they don't exist. > It's the height of hubris as Emacs developers to recommend OS-wide > settings on something like this, and it makes us look like amateurs. Overcommit is very controversial among even the Linux developers, because it works well for some programs and does not for others. IMO, it is reasonable to recommend the option that works best for us, which is to turn overcommit off. Thanks. From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Apr 2022 13:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Po Lu Cc: p.stephani2@gmail.com, mattiase@acm.org, Eli Zaretskii , 54698@debbugs.gnu.org, rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164942325219846 (code B ref 54698); Fri, 08 Apr 2022 13:08:01 +0000 Received: (at 54698) by debbugs.gnu.org; 8 Apr 2022 13:07:32 +0000 Received: from localhost ([127.0.0.1]:34152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncoKq-0005A2-MK for submit@debbugs.gnu.org; Fri, 08 Apr 2022 09:07:32 -0400 Received: from quimby.gnus.org ([95.216.78.240]:60136) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncoKo-00059o-4c for 54698@debbugs.gnu.org; Fri, 08 Apr 2022 09:07:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References: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=gng9n56vwulc5dbWKPuVnRXebonkz9zHs6Mc9mYzPvU=; b=Bd59dRXdsp9AFmPSiNfZsQFkCg jEjLR9n9EM/dSw233INBnzoS2RtJmlvHnxqSaO81aams9yTt1gOO1ovnA1D7CeMcrAPtsoxlQDTPg K4+Tzgak2mNvFF22dYw6/FyWPahm+m2ucvRusfnR80qFi3suAKaf7w1HyGt76y/5r9QI=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ncoKe-00032f-P3; Fri, 08 Apr 2022 15:07:22 +0200 From: Lars Ingebrigtsen References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> <87pmlsw2e9.fsf@yahoo.com> <83bkxcaylu.fsf@gnu.org> <87lewguing.fsf@yahoo.com> <87h773aixt.fsf@gnus.org> <87bkxbu6q3.fsf@yahoo.com> <87czhraicv.fsf@gnus.org> <87zgkvsrc4.fsf@yahoo.com> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAAAAAByaaZbAAAAAmJLR0QA/4ePzL8AAAAJcEhZ cwAACvAAAArwAUKsNJgAAAAHdElNRQfmBAgMOg+A8eacAAAAWUlEQVRIx2P8xkAaYCJR/aiGoaqB BbswIyPD//8kaPi/8QqDjj8pNhxayxCFXcMgDKVRDaMaRjXQUwOOUsOOncEcuwwjjjqOkQF7OYbL BlzKB2UojWqgiQYAgI4L5zQl9tEAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjItMDQtMDhUMTI6NTg6 MTUrMDA6MDC59qptAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIyLTA0LTA4VDEyOjU4OjE1KzAwOjAw yKsS0QAAACZ0RVh0aWNjOmNvcHlyaWdodABubyBjb3B5cmlnaHQsIHVzZSBmcmVlbHlZTA74AAAA FHRFWHRpY2M6ZGVzY3JpcHRpb24Ac1JHQrqQcwcAAAAgdEVYdGljYzptYW51ZmFjdHVyZXIAbGNt cyBnZW5lcmF0ZWQgzUa8gwAAAA50RVh0aWNjOm1vZGVsAHNSR0JbYElDAAAAAElFTkSuQmCC X-Now-Playing: Plastikman & Chilly Gonzales's _Consumed In Key_: "Locomotion (In Key)" Date: Fri, 08 Apr 2022 15:07:20 +0200 In-Reply-To: <87zgkvsrc4.fsf@yahoo.com> (Po Lu's message of "Fri, 08 Apr 2022 20:16:27 +0800") Message-ID: <87lewf9113.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Po Lu writes: > IMO, it is reasonable to recommend the option that works best for us, > which is to turn overcommit off. I don't think so, and neither does Stefan M., but I won't press the issue. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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 (---) Po Lu writes: > IMO, it is reasonable to recommend the option that works best for us, > which is to turn overcommit off. I don't think so, and neither does Stefan M., but I won't press the issue. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: non-recursive GC marking [PATCH] Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Apr 2022 00:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Lars Ingebrigtsen Cc: Po Lu , mattiase@acm.org, p.stephani2@gmail.com, 54698@debbugs.gnu.org, rms@gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.164946414925511 (code B ref 54698); Sat, 09 Apr 2022 00:30:02 +0000 Received: (at 54698) by debbugs.gnu.org; 9 Apr 2022 00:29:09 +0000 Received: from localhost ([127.0.0.1]:36373 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncyyT-0006dP-Eg for submit@debbugs.gnu.org; Fri, 08 Apr 2022 20:29:09 -0400 Received: from smtp-1.orcon.net.nz ([60.234.4.34]:42017) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ncyyR-0006dG-8z for 54698@debbugs.gnu.org; Fri, 08 Apr 2022 20:29:07 -0400 Received: from [10.253.37.70] (port=3371 helo=webmail.orcon.net.nz) by smtp-1.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1ncyyE-0007J2-H8; Sat, 09 Apr 2022 12:28:54 +1200 Received: from ip-139-180-65-103.kinect.net.nz ([139.180.65.103]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Sat, 09 Apr 2022 12:28:54 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 09 Apr 2022 12:28:54 +1200 From: Phil Sainty In-Reply-To: <87lewf9113.fsf@gnus.org> References: <5A577100-75CE-4C9E-A7DA-02B917662AF5@acm.org> <8735itglid.fsf@gnus.org> <8527E407-8190-4574-B8D5-BE68220AE663@acm.org> <871qyc5o0y.fsf@yahoo.com> <5BBEDBDA-4C85-4237-9EF7-5635A4950365@acm.org> <83fsmreox8.fsf@gnu.org> <83a6czekro.fsf@gnu.org> <83r16acwar.fsf@gnu.org> <87tub6zabp.fsf@yahoo.com> <87pmlsw2e9.fsf@yahoo.com> <83bkxcaylu.fsf@gnu.org> <87lewguing.fsf@yahoo.com> <87h773aixt.fsf@gnus.org> <87bkxbu6q3.fsf@yahoo.com> <87czhraicv.fsf@gnus.org> <87zgkvsrc4.fsf@yahoo.com> <87lewf9113.fsf@gnus.org> Message-ID: <407ecc3977e8353cc071663c29595e4b@webmail.orcon.net.nz> X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- 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 (-) On 2022-04-09 01:07, Lars Ingebrigtsen wrote: > Po Lu writes: >> IMO, it is reasonable to recommend the option that works >> best for us, which is to turn overcommit off. > > I don't think so, and neither does Stefan M., but I won't > press the issue. How about we don't "recommend" anything, but instead simply describe the issue and the options available? If users see a *recommendation*, they might follow it without understanding the ramifications. If we're not pressuring users in any direction, then they are less likely to make a change without researching it for themselves. (Indeed we might even "recommend" that they research it for themselves, and provide some pointers to where they can learn more about feature and its pros and cons.) I don't see any harm in pointing out the existence of this feature, but advocating for a non-default configuration seems like a rather dubious idea to me. -Phil From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 27 08:16:02 2022 Received: (at control) by debbugs.gnu.org; 27 Jun 2022 12:16:02 +0000 Received: from localhost ([127.0.0.1]:50184 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o5nes-00055k-1w for submit@debbugs.gnu.org; Mon, 27 Jun 2022 08:16:02 -0400 Received: from mail-oa1-f43.google.com ([209.85.160.43]:40592) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o5nem-000558-8b for control@debbugs.gnu.org; Mon, 27 Jun 2022 08:16:00 -0400 Received: by mail-oa1-f43.google.com with SMTP id 586e51a60fabf-101cdfddfacso12643167fac.7 for ; Mon, 27 Jun 2022 05:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=bGge7F90drnExCtW2kfytjpnMpsNBlOmhD8ckY+6REM=; b=UGjHHUYEmjWSOwMMOquJ2BALX2k8s67ltYH0kPu0qr0LtaMZcdvpAlwCPfgEGJY3O3 5OKdIfyCzlZhT2KGC4/PFb2FTH8MSqFBbwRTXVSOoW1GI6m6SOMquzMwI8kQpML0vKjN DlG4h1AM3a497eRTOPwI4R2SESvDkRTsBG6EkbTB/AU3msxQWo2zIKbSays3ugTLoflA A+Hay9uVbFtj2tF21jT9JbiRGrcwieElHfnbAdsnvBdi+Ex9fKgKyB/z2BkGkU8p41Qa zHiytcjZ3BrhNFiPRN/EgLWoy4AFBHKbGkHi9J2bYQL/zaFc4oPAHLG50T2NARLRZWOS L5AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bGge7F90drnExCtW2kfytjpnMpsNBlOmhD8ckY+6REM=; b=y499TopKeHmLyDYCj1N3YNd8nKkf6wfQ5VK3uU8yfnCIXnlhc5x3rMLRNyrM4Ptsox l8SmwpkR1KLeojE6wq+yISfym5cIUtVNH5N/BhTJluD3vRyX7bOG5P8IJM+CP/0JUuel a5nxlXgsb7BUn6zmweZMpehj5Q8sqggNU7HMdjt/iz7HoDf66WVpColqbTE/mWEbIxHu eDt/kFDcOv67x4KNOL6PR3HRnOBcfQv7XcXQJC9vuEh4BxqLPOcWZrME3v2LVu8bOU6G DHrkU6Jq+wZyThwyQQn1D8zu7vmu4ue+zR8Zu2B2zJ6HkTOvqSZbxnoJZOOnFsLQ01oZ IoOg== X-Gm-Message-State: AJIora8qFEPzrbPaJHUB/f3gCyuMFFUnqdmfSkU95AsQcy5uY21nvnzd Ao19TFQY7sf0FmSk/5bOxaXzb30zmHD2qhIGX/Zq8WQuDlc= X-Google-Smtp-Source: AGRyM1taL2mZJSHYbyNO4ODYn/HSC23O/2wgN+pz7K1ktCXyF40XbU2SIBtWMhu6FUjg0EnKeDExNIiHKl4Mc+LK1gI= X-Received: by 2002:a05:6870:d791:b0:101:ad64:1e74 with SMTP id bd17-20020a056870d79100b00101ad641e74mr7244020oab.162.1656332150208; Mon, 27 Jun 2022 05:15:50 -0700 (PDT) MIME-Version: 1.0 From: Lynn Winebarger Date: Mon, 27 Jun 2022 08:15:38 -0400 Message-ID: Subject: ctl To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) 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: -1.0 (-) unarchive 54698 From unknown Sun Jun 22 00:23:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54698: Fwd: GC mark stack Resent-From: Lynn Winebarger Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Jun 2022 12:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54698 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 54698@debbugs.gnu.org Received: via spool by 54698-submit@debbugs.gnu.org id=B54698.165633287520869 (code B ref 54698); Mon, 27 Jun 2022 12:28:02 +0000 Received: (at 54698) by debbugs.gnu.org; 27 Jun 2022 12:27:55 +0000 Received: from localhost ([127.0.0.1]:50215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o5nqM-0005QU-U6 for submit@debbugs.gnu.org; Mon, 27 Jun 2022 08:27:55 -0400 Received: from mail-oi1-f171.google.com ([209.85.167.171]:45958) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o5nqJ-0005QF-I9 for 54698@debbugs.gnu.org; Mon, 27 Jun 2022 08:27:53 -0400 Received: by mail-oi1-f171.google.com with SMTP id u9so12519575oiv.12 for <54698@debbugs.gnu.org>; Mon, 27 Jun 2022 05:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=l1FBo7BEBaG6oeH6/KwoM4pgDyHzRr9SOrv17NktjOU=; b=qSC3O7PxEUhMkk7Qf57uzPyFimJpCXAqdpGnbuY60I+00Zkq0aaYf49kv3BF7OlOB9 JfVO6FSFuu+LUqxlR8r8tVHIi3GaaUVeMaJ6IhCFU25HQCqIHzdEgvUAYw3XCbe7ttc0 ltPj92fycbdCnJiKrmwm5CmFwDwsqbFwLeVc5rAShk+Qozm/kmoCjKIdlWsW8uE8GXis 6i9994Iv88OLmAOqabznRBs55ZoZQ4wootQT7kx/iGwL4vVAHVr/2ZdAd+gy998L/eTY BT+GXiAV0gyAbpE8CI01B4KGzDWwbuCnelLjROH+/NvNAWCONsARiwr9+TbnakA8bYDw pjbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=l1FBo7BEBaG6oeH6/KwoM4pgDyHzRr9SOrv17NktjOU=; b=IXRCf9NPcDnUUXZ2MD8b+cB9xipR96ZYMYorMmnjFG6tpd06ESnl3YkoFJZg2mdns+ td/jW1C+fBDsm5lbUZNdctSUiD4/Q+ksn2p6axD35agReRyyqkeE2xU0VmkO++/un902 R3xiTnRLqXndwNy3H/P+7U7n1/xreCeKt3qxrMVXFyYPWcZRVtmz5YizHVNkosSpN9Hx MO54CnfbcKdQExpmRPRZh7MseYXcdI6XYj3zNHREdCml7RDObv3CgtOyfvWcKzEbkOSg tlHqIhMJ0aaxN4NndHALHb7Tmw4qye8WVDGll3pFd/MD75dLjFALBKJCkQyN4cUXXUrf tdKw== X-Gm-Message-State: AJIora/0jwWM2bJWNlv4cE8PAosjno7dhvF12y4Qu3H5uppbe4wcr+cZ lP/uiuL+VHYtTaCwMcg5wg5Dcyq0bnXp+s3V3HBOlKUO X-Google-Smtp-Source: AGRyM1tsFeavtoguYjDZsvaENqQprjyOpu9G0lDbE6Ggp+FlL0oDO/hq8pKYTzFPDbkEkhl+SEkA/+3A6fSY5Yn87/A= X-Received: by 2002:a05:6808:1a96:b0:333:289e:713d with SMTP id bm22-20020a0568081a9600b00333289e713dmr7346388oib.247.1656332865374; Mon, 27 Jun 2022 05:27:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lynn Winebarger Date: Mon, 27 Jun 2022 08:27:34 -0400 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: This bug was archived, so I first sent the below to the emacs-devel list. I'm not sure what the best/most appropriate target is for the suggestion. Lynn Forwarded message --------- From: Lynn Winebarger Date: Sun, Jun 26, 2022 at 11:50 AM Subject: Re: GC mark stack To: emacs-devel Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (owinebar[at]gmail.com) -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.171 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.171 listed in list.dnswl.org] -0.0 T_SCC_BODY_TEXT_LINE No description available. 1.2 URI_DOTEDU Has .edu URI 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 (-) This bug was archived, so I first sent the below to the emacs-devel list. I'm not sure what the best/most appropriate target is for the suggestion. Lynn ---------- Forwarded message --------- From: Lynn Winebarger Date: Sun, Jun 26, 2022 at 11:50 AM Subject: Re: GC mark stack To: emacs-devel On Sun, Jun 26, 2022 at 11:31 AM Lynn Winebarger wrote: > > I was reviewing alloc.c in the 28.1 source, and noted that it uses a > semi-naive computation of the transitive closure of the graph of live > data structures (weak hash tables is where I see it). > Since the fix to https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54698 > (commit 7a8798de95a57c8ff85f070075e0a0176b458578) moved to using an > explicit stack, I was curious if you'd considered using a variant of > Tarjan's SCC algorithm, such as the one described in > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.40.9019&rep=rep1&type=pdf > , > to guarantee that each edge is traversed at most once. The algorithm > described never removes traversed objects from its stack (so it can > tell when an object has already been traversed, even if the current > link into it is not part of its SCC). > The algorithm would only need to account for objects like weak hash > tables, so a direct implementation would only leave those on the > stack. An alternative would be to create an additional field in the > objects (like weak hash table) recording the order in which they were > traversed, which also makes the algorithm more efficient since there's > no stack search involved when determining the SCC representative of > particular node - it's just a matter of comparing their stack > ordering. > Of course, I don't have any idea how much time is spent on this type > of recursion for weak references. The SCC-based algorithms can make a > significant performance improvement compared to semi-naive calculation > of transitive closure for general relational queries. It might not be > so useful when you don't require an explicit enumeration of the set of > answers. I should point out here, that with only strong references, there's only one SCC of interest (liveness) and the mark-bit is exactly the stack-traversal-ordering count I suggested as an alternative to keeping items on the stack as in the implementation described in the paper. For the more general problem of weak references, the algorithm requires explicitly tracking the SCC candidate sets and representatives. Those structures can also be "pre-allocated" in the weak reference objects if allocation during garbage collection is an issue. Lynn