python 3.14 garbage collector *REVERTED*

Added: 2026-05-11

[00:00:01]Hello and welcome to another video. In this one, we're going to be talking about the Python 3.4 release cycle. Uh, you may have noticed that 314 has been out for a while. So, it's a bit strange to talk about it, but there is a new release which is following a bit of a I don't want to say unprecedented because I think something similar has happened in the past, but a pretty significant change very late into uh the release cycle of a minor version of Python, which is a significant revert is happening to the garbage collector.

[00:00:34]Um, I don't even think I bothered mentioning this in my Python 3.4 14 video just cuz I mean it didn't seem like that big of a deal at the time. But uh the garbage collector actually changed in Python 3.14. We'll talk a little bit about why and how it changed and kind of the the rationale behind it.

[00:00:51]Um but it turns out this change uh significantly changed how some programs operate and results in some pretty significant uh memory pressure in a lot of applications. Um, but I guess let's talk about like uh what what happened first like why why did they even try and do this in the first place and this was an idea that came out of well you can't see the little dot dot dot here but the faster CPython project the idea of know one of the many ideas of taking Python and improving its speed uh by tackling various parts of the uh interpreter itself and one part of the interpreter is garbage collection. I guess I should say what is garbage collection before I even talk about this further. Uh which is that pi in in python in C python I guess technically in other implementations they have different approaches to this uh but in CPython when you have an object uh let's say we have I don't know class C and give it a body we make an instance of C this is an object that has a reference count you can look at that by doing get ref count on it. uh this will actually say two I believe because um the parameter being passed into this function also increments the reference count here. So there are two references one being this this object here uh if we assign it to none this actually doesn't go through garbage collection um or if we delete this object we've removed the reference to this instance here and its reference count has dropped to zero and the object has been deleted. Garbage collection doesn't get involved here even though this you could think of this as a garbage collection type of thing.

[00:02:24]Uh this is just basic reference counting. Where garbage collection gets involved is when you have a cycles an object. So if we make a C again and we uh cause a cycle. So the attribute X refers to itself. Um and so we look at I guess we can even get a ref count again. You can see it has a ref count of three. One of those is an internal cycle inside this object. Um, it is an object that contains itself. I guess the more common example of this is to make a a list and then uh append it to itself.

[00:02:59]Whoa. Recursive list. Um, and actually the repper handles this properly and shows that like there's there's some recursive nonsense going on here. So, it shows an ellipsus. But in this case, this is a circular object. And this is where garbage collection comes into play. Uh garbage collection is a process that the interpreter does occasionally and it finds objects uh that are unreachable but are you know reachable internally and then it destructs them.

[00:03:25]So otherwise these cycles would live forever uh but the garbage collection process can clean them up at least that's the idea here.

[00:03:34]And so we talk about incremental GC.

[00:03:36]This is a change to the garbage collection algorithm which intended to improve the performance. Um I've made overly simplified diagrams of how garbage collection works today in CPython. I guess today being like the classic garbage collection and then the new incremental garbage collection. So the basic idea with classic uh garbage collection is there are three generations. a generation just being like a collection of garbage collectible objects. Uh the youngest objects start in generation zero. This is the one that is scanned most often to try and uh delete objects. The idea being that most objects in a Python application are short-lived. And so cycles should be generally short-lived. And so you scan the things that are most likely to be deleted as early as possible so that they don't live as long as as possible.

[00:04:26]Um, and so this is kind of the the first generation of scanning here. And this thing get this gen zero gets scanned the most often. Uh, if things survive gen zero, they end up in the older generations. And it's the same algorithm generally for all three of these. If it has to do a full garbage collection scan, which I believe happens after some number of iterations of attempting a younger scan or after some amount of memory pressure. I'm not actually certain how it chooses to do it, but if it does a full scan, it's going to do all three generations at the same time.

[00:04:57]Uh, but things in Gen 2 are kind of the rarest generation that gets collected.

[00:05:02]Um, there's also frozen garbage collection objects which don't get collected and immortal object and there's there's a bunch of other complexity here, but we're not going to talk about that today. We're just going to be talking about this sort of generational approach here. So, this is kind of how the classic garbage collection works. Um, in this model here, you're scanning a lot of objects all the time. Like anytime you have to do a gen one scan or anytime you have to do a gen two scan, you're scanning essentially the entire heap of Python and looking at every single object that's currently alive. And looking at every single object that's currently alive can take a lot of time, especially if a lot of them aren't even going to be garbage collectible. You might be looking at a bunch of objects that uh would never die. Like there's there's just permanently referenced. um and but the garbage collection will still check them. In the incremental model, the idea was to take these three generations, reduce it down to two and a halfish um a a young generation, which looks very much like the gen zero uh um generation here, which is just any of the recent objects that haven't been scanned yet. Uh when things are scanned in the young generation, they are sent to the old generation inside its scanned list. uh things that it has already recently scanned. So it thinks, oh, I don't have to scan this for a while. Uh I'll just trust that these are good. Uh and then occasionally the old generation is scanned, but just part of this pending list. Uh you might ask, well, how does the pending list happen? Uh eventually when the pending list is empty, these two pending and scanned are swapped. And so it it still will eventually get to cycles in this. The idea behind this incremental garbage collection is we have to scan fewer objects less often and so it should reduce the impact of running the garbage collector during normal operation of of the interpreter. However, um you may notice, you know, just talking about this that like, hey, if we're only scanning a portion of pending and it takes a while for this pending to get exhausted, um you know, we're constantly appending to scanned here. Uh we're only doing like one pass at generation zero, whereas before we kind of had this like step up of of of garbage collecting, we're doing it a lot less often. Doesn't this mean that objects live a lot longer? And yeah, that's kind of the problem that ended up happening here is that objects ended up living a lot longer. Um, but let's talk about, you know, the the the [gasps] storied uh attempts to implement this incremental garbage collector, how it got into 314, why why it's finally being reverted again in 314. Um, and I guess also 315 because uh 315 is not out yet, but um it's also being reverted there as well. Okay, but anyway, this was original idea way back in 2023. It is 2026 now, so it's been several years of trying to implement this. Um, just kind of a a theory idea of the the algorithm. This is basically what was implemented. Um, obviously the the constants here and the percentages here were tweaked a lot and like there was some additional complexity on top of this to look at like memory pressure and other stuff there. But for the most part, this is the algorithm that got implemented. Um this was actually originally contributed in Python 3.13 uh in this PR which implements the actual uh garbage collection here and was later reverted in um in 313 uh and an additional round of release candidates were added. Uh there was some performance regressions that were shown.

[00:08:43]There were actually a lot of performance regressions shown here. Uh if you look at this patch here, there's is it this one?

[00:08:52]One of these patches. Yeah, there's just like a whole bunch of references to this as it's slowing down and eventually it was reverted out in 313 so that um the release could go out with lower impact stuff going there. Um, you may also notice, and this will come up later, uh, this this, um, this implementation here, uh, here didn't go through a PEP. This was something that I think was pretty sign a pretty significant change. Well, obviously, I didn't think it was significant enough to put it in my video, but [laughter] a pretty significant change to Python, uh, that didn't go through the PEP process. Um, and so this is I think something that they're learning from this and and next time that this is attempted, there will be a pet process for changing the garbage collector. Um, which I I'm I'm still very surprised it didn't in the first place because the garbage collector is a pretty core part of how Python works and changing something that significantly kind of a big deal. But anyway, didn't go through the pet process. probably part of the reason that it didn't get as much scrutiny and and perhaps part of the reason that it's been doomed twice now. Um, but anyway, this is the issue that was open for Python 3.14 where people noticed that there was increased memory pressure. Uh fortunately someone was able to find a minimal reproduction here that um that kind of narrowed down uh I guess a pathological case of um memory you know going up over time not being collected in a reasonable manner.

[00:10:22]Uh and this was just a simple example using I think HTTPX. Yeah. So just an HTP client and allocations in the SSL library uh were not being cleaned up in any reasonable fashion. Kind of the idea or at least looking at this graph here.

[00:10:38]Um my my my guess on what was happening is like a lot of things were being pushed into this scanned list and then only occasionally it was moving to pending and so eventually the objects would all get collected but they were just accumulating much faster than they were being purged here. And so you kind of get this this up and to the right graph. You can see that there are some collections here. Like you look at resonant set size, there are some small down ticks here. And this is this is probably when the portion of the old generation is collected, but you can see it's still it's still up and to the right over time. And so it is not um keeping up with the the memory pressure here. At least that's my guess on this.

[00:11:17]I didn't look too closely into it.

[00:11:20]That's just my intuition here. I could be wrong though. I'm probably wrong, let's be real. Um, cool. But anyway, yeah, they there there's this observed leak and so uh it's being reverted and um I haven't seen something this late this big being reverted in Python. So this this is why I felt that this was a important enough thing to cover in a video. Um, there was also a very long thread discussing and yeah, I did read it all and there wasn't really much much of interest in here other than I believe they're going to go through the PEP process to reintroduce this not in 315 but in Python 316. Um, if at all they may find that this new garbage collection algorithm isn't actually significantly better and that will be, you know, with the classic algorithm indefinitely. Uh but anyway, wanted to cover this uh wanted to cover the you know storyried [laughter] difficulty in getting this this algorithm in but also kind of a a highle view of how it works and um I still don't know why the pet process wasn't followed but hopefully it will be next time. Anyway, hopefully you found this useful. If there are additional things you would like me to explain, leave a comment below or reach out to me on the various platforms. But thank you all for watching and I will see you in the next one.