Reverting the incremental GC in Python 3.14 and 3.15 • Hacker News Board

Re: Reverting the incremental GC in Python 3.14 and 3.15

#71

Post by coldtea » Wed, May 13, 2026, 10:36 PM UTC

JackSlateur wrote: post #66

pron wrote: post #28

Earlier quoted context omitted.

Java lost almost all those knobs a while ago (I mean they're there, but you're better off relying on the defaults). The modern GCs have one or at most two knobs remaining, and even that will become unnecessary next year. As to predictablity, you get maximal pause time of well under 1ms for heaps up to 16TB.

As far as I know, java has 7 GC implementations, none of which are perfect, all of which have drawbacks Lately, they seems to work with CRIU, various heuristics, multi-stage in-process bytecode compilation .. Java is a mess, they are working hard to avoid fixing their issue (that nobody else have, so fixes are available)

>As far as I know, java has 7 GC implementations, none of which are perfect, all of which have drawbacks

Compared to Python's, all of them are beyond perfect. And 99.9% of the time you don't even need to use anything but the default.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#72

Post by davidkwast » Wed, May 13, 2026, 10:45 PM UTC

giancarlostoro wrote: post #64

zitterbewegung wrote: post #52

Earlier quoted context omitted.

I wouldn’t recommend running the latest Python in prod. Honestly 3.x.7 releases are the most mature .

I'm currently in a .NET shop so not an issue for me, makes me wonder if Python will eventually adopt the concept of LTS releases, this could have been avoided as an issue if it was part of a non-LTS release.

All Python versions are LTS if you consider 5-year a good measure.

https://devguide.python.org/versions/

Re: Reverting the incremental GC in Python 3.14 and 3.15

#73

Post by nas » Wed, May 13, 2026, 10:46 PM UTC

athoscouto wrote: post #23

We've been impacted by this. I migrated our services to Python 3.14 so we could attach profilers during runtime. A couple of services looked like they had a memory leak. Memory was continuously increasing over time. Thanks to Python 3.14, we were able to use memray to understand what was going on. Those services were recreating HTTP clients (aiohttp) for every inbound request, and memory allocated by the downstream S…

If you are using "httpx", it's likely caused by a reference cycle. I made a PR to fix it but the maintainers haven't applied it. :-( https://github.com/encode/httpx/pull/3733

The reference cycle httpx creates is kind of a worst-case scenario for the incremental GC issue. Both the generational (3.13 and older) and incremental GC are triggered by the net new "container" objects (objects that have references to others, like lists and not like ints and floats). The short summary is that you need to create more container objects before the incremental GC triggers. In the case of the httpx reference cycle, you have a relatively small number of container objects hanging on to a lot of memory, due the SSL context data (which is a big memory hog).

Reverting back to the generational GC was the wise thing to do, even though it's a bit scary to do in a bugfix release. The incremental GC works for most people but in the minority of cases it doesn't, it uses quite a lot more memory. I'm pretty sure with some additional tuning, the incremental GC would be fine too but it just didn't get that tuning. The generational GC has literal decades of real-world use (Guido merged my patch on Jun 2000, Tim Peters did a bunch of tuning after that to optimize it).

Re: Reverting the incremental GC in Python 3.14 and 3.15

#74

Post by 3836293648 » Wed, May 13, 2026, 10:56 PM UTC

lijok wrote: post #43

__loam wrote: post #38

Earlier quoted context omitted.

[flagged]

We should all go back to writing assembly

> X is a terrible language because of the lack of static analysis available.

> (Mocking) Yes, that's why we should go back to Y with even worse static analysis.

Sure

Re: Reverting the incremental GC in Python 3.14 and 3.15

#75

Post by winrid » Wed, May 13, 2026, 11:01 PM UTC

pron wrote: post #28

winrid wrote: post #13

Earlier quoted context omitted.

The main benefit of python to me is that while slow, it's predictable. I do think they're going to get a lot more resistance to adding JITs, moving GCs, etc. it will become java with a million knobs to tune. If people want a JIT'd python just use pypy, right?

Java lost almost all those knobs a while ago (I mean they're there, but you're better off relying on the defaults). The modern GCs have one or at most two knobs remaining, and even that will become unnecessary next year. As to predictablity, you get maximal pause time of well under 1ms for heaps up to 16TB.

The max pause time thing is a meme :) I have gotten multi second pause times with ZGC. It depends on what hardware you run it on.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#76

Post by aidenn0 » Thu, May 14, 2026, 12:14 AM UTC

davidkwast wrote: post #72

giancarlostoro wrote: post #64

Earlier quoted context omitted.

I'm currently in a .NET shop so not an issue for me, makes me wonder if Python will eventually adopt the concept of LTS releases, this could have been avoided as an issue if it was part of a non-LTS release.

All Python versions are LTS if you consider 5-year a good measure. https://devguide.python.org/versions/

If all releases are LTS, then none are. Part of the point GP was making is that when some releases have a very short maintenance window, then changes that are terrible in them don't need to be reverted (since the maintenance window will close soon anyways).

Re: Reverting the incremental GC in Python 3.14 and 3.15

#77

Post by refulgentis » Thu, May 14, 2026, 12:24 AM UTC

pron wrote: post #28

winrid wrote: post #13

Earlier quoted context omitted.

The main benefit of python to me is that while slow, it's predictable. I do think they're going to get a lot more resistance to adding JITs, moving GCs, etc. it will become java with a million knobs to tune. If people want a JIT'd python just use pypy, right?

Java lost almost all those knobs a while ago (I mean they're there, but you're better off relying on the defaults). The modern GCs have one or at most two knobs remaining, and even that will become unnecessary next year. As to predictablity, you get maximal pause time of well under 1ms for heaps up to 16TB.

Next year? Do tell

Re: Reverting the incremental GC in Python 3.14 and 3.15

#78

Post by rtpg » Thu, May 14, 2026, 12:27 AM UTC

athoscouto wrote: post #23

We've been impacted by this. I migrated our services to Python 3.14 so we could attach profilers during runtime. A couple of services looked like they had a memory leak. Memory was continuously increasing over time. Thanks to Python 3.14, we were able to use memray to understand what was going on. Those services were recreating HTTP clients (aiohttp) for every inbound request, and memory allocated by the downstream S…

We've been chasing down similar aiohttp client creation issues (liked to ...aiobotocore usage) for months now.

It's annoying that somehow talking to S3 etc requires so much churn. We have been trying to cache session objects and the like but clearly are still missing something.

Chasing this down has also made me realize how little Python libs use `weakref`, and just will build up so many circular references. The other day I figured out Django request's session infrastructure creates a circular reference meaning that requests have to get GC'd to get cleaned up in CPython.

I have a suspicion that the 3.14 problems are heavily linked to "real" workloads being almost entirely filled with cyclical objects.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#79

Post by refulgentis » Thu, May 14, 2026, 12:28 AM UTC

coldtea wrote: post #71

JackSlateur wrote: post #66

Earlier quoted context omitted.

As far as I know, java has 7 GC implementations, none of which are perfect, all of which have drawbacks Lately, they seems to work with CRIU, various heuristics, multi-stage in-process bytecode compilation .. Java is a mess, they are working hard to avoid fixing their issue (that nobody else have, so fixes are available)

> As far as I know, java has 7 GC implementations, none of which are perfect, all of which have drawbacks Compared to Python's, all of them are beyond perfect. And 99.9% of the time you don't even need to use anything but the default.

> Compared to Python's, all of them are beyond perfect.

I somehow understand the situation less after reading this.

Is Python's GC bad, or are there cyclic reference issues? Is it possible to detect cyclic references perfectly? What does beyond perfect mean? If we have 7 and 0.1% of the time you need one of the 6 that is non-default, how do we choose? Is the understated version of "Compared to Python's, all of them are beyond perfect" "I think Java's are great"? If not, what about Python's impl makes it so lackluster to any of 7 of Java's?

Re: Reverting the incremental GC in Python 3.14 and 3.15

#80

Post by egl2020 » Thu, May 14, 2026, 1:20 AM UTC

zozbot234 wrote: post #45

winrid wrote: post #13

Earlier quoted context omitted.

The main benefit of python to me is that while slow, it's predictable. I do think they're going to get a lot more resistance to adding JITs, moving GCs, etc. it will become java with a million knobs to tune. If people want a JIT'd python just use pypy, right?

Why not just use Go? It has a proper concurrent, non-moving GC that, AIUI, has not been associated with sudden memory spikes.

Libraries. I use both languages, and a survey of what libraries are available is part of picking an implementation language when starting a greenfield project.