aboutsummaryrefslogtreecommitdiffstats
path: root/admin
diff options
context:
space:
mode:
authorGerd Möllmann2024-12-28 07:01:55 +0100
committerGerd Möllmann2024-12-28 07:03:41 +0100
commit5675290ef8a60bedd102d4ef124e25786442dfaf (patch)
treef4fd4d4b65aeab1e48bc8f371d54726e2836b65c /admin
parentbd2da5282db50676d97b65f1d61101aafbc9a3ff (diff)
downloademacs-5675290ef8a60bedd102d4ef124e25786442dfaf.tar.gz
emacs-5675290ef8a60bedd102d4ef124e25786442dfaf.zip
igc.org: Pdump, new section
Diffstat (limited to 'admin')
-rw-r--r--admin/igc.org38
1 files changed, 38 insertions, 0 deletions
diff --git a/admin/igc.org b/admin/igc.org
index 1207675a1e8..04626b2c5a7 100644
--- a/admin/igc.org
+++ b/admin/igc.org
@@ -327,3 +327,41 @@ receive in =igc_process_messages=. We call =finalize= on the object
327contained in the message, and =finalize= dispatches to various subroutines 327contained in the message, and =finalize= dispatches to various subroutines
328with the name prefix =finalize_= to do the finalization for different Lisp 328with the name prefix =finalize_= to do the finalization for different Lisp
329object types. Examples: =finalize_font=, =finalize_bignum=, and so on. 329object types. Examples: =finalize_font=, =finalize_bignum=, and so on.
330
331* Pdump
332
333Emacs' portable dumper (pdumper) writes a large number of Lisp objects
334into a file when a dump is created, and it loads that file into memory
335when Emacs is initialized.
336
337in an Emacs using the traditional GC, once the pdump is loaded, we have
338the following situation:
339
340- The pdump creates in a number of memory regions containing Lisp
341 objects.
342- These Lisp objects are used just like any other Lisp object by
343 Emacs. They are not read-only, they can be modified.
344- Since the objects are modifiable, the traditional GC has to scan
345 them for references in its mark phase.
346- The GC doesn't sweep the objects from the pdump, of course. It can't
347 because the objects were not not allocated normally, and there's no
348 need to anyway.
349
350With igc, things are a bit different.
351
352We need to scan the objects in the pdump for the same reason the old GC
353has to. To do the scanning, we could make the memory areas that the
354pdumper creates roots. This is not a good solution because the pdump is
355big, and we want to keep the number and size of roots low because this
356has an impact on overall GC performance.
357
358What igc does instead is that it doesn't let the pdumper create memory
359areas as it does with the traditional GC. It allocates memory from MPS
360instead.
361
362The Lisp objects contained in the pdump are stored in a way that they
363come from a pdump becomes transparent. The objects are like any other
364Lisp objects that are later allocated normally.
365
366The code doing this can be found in =igc_on_pdump_loaded,= =igc_alloc_dump=,
367and their subroutines.