Bug report
Bug description:
There is some inconsistency in handling of immortal objects in default-build's GC.
In update_refs immortal objects just untracked (all immortal objects that we face in GC is an accidentally immortalized).
|
if (_Py_IsImmortal(op)) { |
|
assert(!_Py_IsStaticImmortal(op)); |
|
_PyObject_GC_UNTRACK(op); |
|
gc = next; |
|
continue; |
|
} |
update_refs called for all collections (young, increment and full). But for incremental collection if increment_size < gcstate->work_to_do we steal some objects from neighbor gen and call expand_region_transitively_reachable where immortal objects moved to permanent generation:
|
if (_Py_IsImmortal(op)) { |
|
PyGC_Head *next = GC_NEXT(gc); |
|
gc_list_move(gc, &gcstate->permanent_generation.head); |
|
gc = next; |
|
continue; |
|
} |
So, one part of immortal objects can be untracked, and other part can be moved to perm gen.
As I understand from #127519 it is preferring to untrack immortal objects in all cases.
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Linked PRs
Bug report
Bug description:
There is some inconsistency in handling of immortal objects in default-build's GC.
In
update_refsimmortal objects just untracked (all immortal objects that we face in GC is an accidentally immortalized).cpython/Python/gc.c
Lines 495 to 500 in 1e69cd1
update_refscalled for all collections (young, increment and full). But for incremental collection ifincrement_size < gcstate->work_to_dowe steal some objects from neighbor gen and callexpand_region_transitively_reachablewhere immortal objects moved to permanent generation:cpython/Python/gc.c
Lines 1397 to 1402 in 1e69cd1
So, one part of immortal objects can be untracked, and other part can be moved to perm gen.
As I understand from #127519 it is preferring to untrack immortal objects in all cases.
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Linked PRs