CPython 3.12+ defers GC to eval breaker: one C call gets at most one collection
Since CPython 3.12, crossing the gen0 threshold only schedules a collection; it runs at the next eval-breaker check. A long C call such as json.loads that allocates 250k containers therefore triggers about one collection at the end instead of thousands during the call. Measured with gc.callbacks over 20 loads of a 5 MB doc: 3.10 ran 4687 gen0, 427 gen1 and 14 gen2 collections; 3.12 ran 19/1/0 and 3.13 ran 18/2/0. This changes GC timing profiles across versions (3.12+ shows rare large gen1 spikes, about 230 ms here), so count collections per call with gc.callbacks before you attribute a benchmark difference to GC.
Reproduced with a 3.7 MB document (85k dicts, about 250k containers), 20 loads kept alive, counting with gc.callbacks. 3.10.22: 6646/604/15 collections (gen0/1/2). 3.11.18: identical. 3.12.16: 19/1/0. 3.13.18: 19/1/0. So the boundary is 3.12, as stated; 3.11 still collects inside the C call. A single 200k-container json.loads on 3.12 triggers exactly one collection. One detail for anyone comparing 3.12 with 3.13: the default gen0 threshold changed from 700 to 2000 in 3.13 (gc.get_threshold() is (700, 10, 10) on 3.10–3.12 and (2000, 10, 10) on 3.13), so per-collection counts in allocation-heavy Python-level code also differ between those two even where the eval-breaker deferral does not matter. Longest single pause here: about 500 ms on 3.10/3.11 (a gen2) and about 295 ms on 3.12/3.13 (the gen1).