Live data from Hacker News

Reverting the incremental GC in Python 3.14 and 3.15

discuss.python.org

21–30 of 134 posts

Re: Reverting the incremental GC in Python 3.14 and 3.15

#21

Earlier quoted context omitted.

And if people want python with java, there's always Jython.

jython has been basically unmaintained for quite some time

Well, they never made the jump to Python 3. But shipping 2.7 interpreters in 2024 was quite an achievement on its own. So their users already know this pain. And from my experience in academia, python 2.7 and java 8 will probably be used for another 20 years before the last machine running that stuff burns out.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#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 SSL lib was growing faster than it was being released.

We ended up rolling back to 3.13, which fixed the issue. I'll try again with 3.14.5.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#24

In the world of AI written code, Python just doesn’t make sense. Converted about 100k lines in the last few months to golang and the performance is life changing. Curious if we will see global Python adoption fall by 75% or more in the next few years.

I think we'll eventually be generating machine code directly. But until then we should be using code that our team can actually read and understand. If you know go, then that works you, Not everyone does.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#25

.NET seems to have regularly changed the garbage collector over the years and I do not remember any similar surprises in production. I wonder why they have had better experience? I thought that by now dynamic garbage collection was a known quantity so that making changes, outside of out right bugs, is fairly safe and predictable?

Actually there’s a change to dotnet 9 with how it handles the heap and GC which caused major issues for us.

I’ll confess the reason it hit us so hard is because the code quality was so low and wasteful on allocations that it didn’t hide the problem as well as previous versions.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#26
post #13

"Python 3.14 shipped with a new incremental garbage collector. However, we’ve had a number of reports of significant memory pressure in production environments. We’ve decided to revert it in both 3.14 and 3.15, and go back to the generational GC from 3.13." Sounds the right move for me

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?

Resistance from anyone who matters to the developers?

Re: Reverting the incremental GC in Python 3.14 and 3.15

#27
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?

And if people want python with java, there's always Jython.

Jython is unmaintained, I'd recommend Clojure. Use python libraries and code while seamlessly targeting the JVM.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#28
post #13

"Python 3.14 shipped with a new incremental garbage collector. However, we’ve had a number of reports of significant memory pressure in production environments. We’ve decided to revert it in both 3.14 and 3.15, and go back to the generational GC from 3.13." Sounds the right move for me

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.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#29

.NET seems to have regularly changed the garbage collector over the years and I do not remember any similar surprises in production. I wonder why they have had better experience? I thought that by now dynamic garbage collection was a known quantity so that making changes, outside of out right bugs, is fairly safe and predictable?

I remember working on the Windows Update back-end at Microsoft around 2005, and we had a problem where it would freeze up periodically, and not surprisingly that turned out to be caused by GC. But we noticed it before shipping, and we just tweaked some GC parameters.

So I think it was not a big problem for .Net because it gave you enough control over GC, and because people tested their code before putting it in production.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#30

I think reverting is not problem per se, but releasing a highly problematic version without proper testing in such an essential component is.

Yeah they noted that it went without PEP. Looks like a PEP will come now if it maintains at par perf.
Post reply on HN