From 210f30b25fe17ec98cfa04108c5531a799ead1d4 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Sun, 12 Jan 2025 11:07:29 +0100 Subject: [PATCH] * admin/igc.org: Document that MPS is asynchronous. --- admin/igc.org | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/admin/igc.org b/admin/igc.org index 56d9b02a34b..f2d8b714a4f 100644 --- a/admin/igc.org +++ b/admin/igc.org @@ -74,6 +74,8 @@ The traditional mark-sweep GC implementation is the addresses where their initial allocation puts them. Special facilities like allocation in blocks are implemented to avoid memory fragmentation. +- Synchronous. In C code, garbage collection happens only at predictable + synchronization points. In Lisp code, there are no such guarantees. In contrast, the new igc collector, using MPS, is @@ -84,6 +86,9 @@ In contrast, the new igc collector, using MPS, is fragmentation. Special care must be taken to take into account that the same Lisp object can have different addresses at different times. +- Asynchronous. This means that MPS might be scanning, moving, or + collecting, at any point in time (potentially, between any pair of + instructions). The goal of igc is to reduce pause times when using Emacs interactively. The properties listed above which come from leveraging @@ -248,10 +253,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 -- 2.47.1