diff options
| author | Gerd Möllmann | 2024-12-28 07:01:55 +0100 |
|---|---|---|
| committer | Gerd Möllmann | 2024-12-28 07:03:41 +0100 |
| commit | 5675290ef8a60bedd102d4ef124e25786442dfaf (patch) | |
| tree | f4fd4d4b65aeab1e48bc8f371d54726e2836b65c /admin | |
| parent | bd2da5282db50676d97b65f1d61101aafbc9a3ff (diff) | |
| download | emacs-5675290ef8a60bedd102d4ef124e25786442dfaf.tar.gz emacs-5675290ef8a60bedd102d4ef124e25786442dfaf.zip | |
igc.org: Pdump, new section
Diffstat (limited to 'admin')
| -rw-r--r-- | admin/igc.org | 38 |
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 | |||
| 327 | contained in the message, and =finalize= dispatches to various subroutines | 327 | contained in the message, and =finalize= dispatches to various subroutines |
| 328 | with the name prefix =finalize_= to do the finalization for different Lisp | 328 | with the name prefix =finalize_= to do the finalization for different Lisp |
| 329 | object types. Examples: =finalize_font=, =finalize_bignum=, and so on. | 329 | object types. Examples: =finalize_font=, =finalize_bignum=, and so on. |
| 330 | |||
| 331 | * Pdump | ||
| 332 | |||
| 333 | Emacs' portable dumper (pdumper) writes a large number of Lisp objects | ||
| 334 | into a file when a dump is created, and it loads that file into memory | ||
| 335 | when Emacs is initialized. | ||
| 336 | |||
| 337 | in an Emacs using the traditional GC, once the pdump is loaded, we have | ||
| 338 | the 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 | |||
| 350 | With igc, things are a bit different. | ||
| 351 | |||
| 352 | We need to scan the objects in the pdump for the same reason the old GC | ||
| 353 | has to. To do the scanning, we could make the memory areas that the | ||
| 354 | pdumper creates roots. This is not a good solution because the pdump is | ||
| 355 | big, and we want to keep the number and size of roots low because this | ||
| 356 | has an impact on overall GC performance. | ||
| 357 | |||
| 358 | What igc does instead is that it doesn't let the pdumper create memory | ||
| 359 | areas as it does with the traditional GC. It allocates memory from MPS | ||
| 360 | instead. | ||
| 361 | |||
| 362 | The Lisp objects contained in the pdump are stored in a way that they | ||
| 363 | come from a pdump becomes transparent. The objects are like any other | ||
| 364 | Lisp objects that are later allocated normally. | ||
| 365 | |||
| 366 | The code doing this can be found in =igc_on_pdump_loaded,= =igc_alloc_dump=, | ||
| 367 | and their subroutines. | ||