From ba4aea03096099f628ddaf4b59a8ca79ce4b42c2 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Sun, 12 Jan 2025 11:07:29 +0100 Subject: [PATCH] Document when GC happens with IGC * admin/igc.org: Document when GC happens. Ref: https://lists.gnu.org/r/emacs-devel/2025-01/msg00360.html --- admin/igc.org | 37 +++++++++++++++++++++++++++++++++---- 1 file changed, 33 insertions(+), 4 deletions(-) diff --git a/admin/igc.org b/admin/igc.org index 56d9b02a34b..f43438a9129 100644 --- a/admin/igc.org +++ b/admin/igc.org @@ -89,6 +89,8 @@ The goal of igc is to reduce pause times when using Emacs interactively. The properties listed above which come from leveraging MPS make that possible. +Note that MPS is not currently concurrent, however. + * MPS (Memory Pool System) The MPS (Memory Pool System) is a C library developed by Ravenbrook @@ -248,10 +250,9 @@ pointers or Lisp_Objects. With the traditional GC, frequently, inadvertently collecting such objects is prevented by inhibiting GC. -With igc, we do things differently. We don't want to temporarily stop -the GC thread to inhibit GC, as a design decision. Instead, we make -the =malloc'd= memory a root, which is destroyed when the memory is -freed. +With igc, we do things differently. We don't want to temporarily +inhibit GC, as a design decision. Instead, we make the =malloc'd= memory +a root, which is destroyed when the memory is freed. igc provides a number of functions for doing such allocations. For example =igc_xzalloc_ambig=, =igc_xpalloc_exact= and so on. Freeing the @@ -302,6 +303,34 @@ Here is how this is done, simplified: igc_free (t) #+end_src +* When does GC happen? + +From the point of view of Lisp code, there are never any guarantees +about when GC happens, neither with the traditional or MPS-based GC. + +However, the old GC has two variables that can be used by Lisp code to +have some amount of control how and when GC happens: =gc-cons-threshold= +and =gc-cons-percentage=. With IGC, we have given that control over to +the MPS library, which decides when to trigger garbage collection +according to its own heuristics. This means that the mentioned +variables no longer have an effect. + +With the traditional GC, you can also explicitly trigger a full GC, by +calling the function =garbage-collect=. With IGC, this is no longer the +case, though that function does still perform some necessary internal +cleanups. The statistics returned by that function are also not +accurate with IGC. + +The story is a bit different in C. Using the traditional GC, C code +could rely on garbage collection happening only at predictable points in +time. This means that GC couldn't happen in C code, as long as it +didn't call out to Lisp, or explicitly called GC itself. + +With MPS, the GC "might be scanning, moving, or collecting, at any point +in time (potentially, between any pair of instructions)" (Memory Pool +System Guide, ch. 2). For this reason, we try to write C code without +making any non-GC assumptions. + * Finalization For some Lisp object types, Emacs needs to do something before a dead -- 2.48.0