☰ Menu

30.09.2026 · Signal Titans Editorial

Python-Kernentwickler diskutieren über kombinierten Garbage Collector

Beim Language Summit diskutierten Python-Kernentwickler über hybride Garbage-Collection-Strategien nach Speicherproblemen in Python 3.14.

Eine konzeptionelle Illustration einer Balkenwaage mit einer grünen Kugel für Speichereffizienz auf der einen Seite und einer blauen Sanduhr für reduzierte Pausenzeiten auf der anderen Seite.

Auf dem Python Language Summit 2026 stellte Kernentwickler Mark Shannon ein Konzept für eine hybride Garbage Collection vor, die generationenbasierte und inkrementelle Ansätze kombiniert. Der Vortrag folgte auf das Zurücksetzen des experimentellen inkrementellen Collectors von Python 3.14 auf den generationenbasierten Collector von Python 3.13, nachdem in Produktionsumgebungen erheblicher Speicherdruck gemeldet worden war.

Balance zwischen Pausenzeiten und Speicherbedarf

Python verlässt sich bei der Speicherverwaltung in erster Linie auf Referenzzählung. Der zyklenerkennende Garbage Collector dient dabei als Ergänzung, auf die etwa 11,67 % der Ausführungszeit entfallen. Während der generationenbasierte Collector aus Python 3.13 insgesamt einen geringeren Speicherverbrauch beibehält, kann er maximale Pausenzeiten von rund drei Sekunden verursachen. Der für Python 3.14 eingeführte inkrementelle Collector reduzierte die maximalen Unterbrechungen zwar erfolgreich auf wenige Millisekunden, führte jedoch aufgrund seines nicht-generationenbasierten Aufbaus zu einem erhöhten Speicherbedarf bei großen Heaps.

Shannon berichtete, dass beide bisherigen Ansätze eine geringe Effizienz bei der Bereinigung aufweisen – gemessen am Verhältnis von gesammelten zu überprüften Objekten. Der generationenbasierte Collector erreicht hierbei einen Wert von 0,3 %, während der inkrementelle Collector bei etwa 1 % liegt.

Vorgeschlagene hybride Collector-Strategie

Um den Zielkonflikt zwischen Pausendauer und Speicher-Overhead zu lösen, skizzierte Shannon eine einheitliche Architektur mit zwei Generationen: einer 20 MB großen jungen Generation und einer alten Generation. Der Entwurf sieht vor, inkrementelle Bereinigungsdurchläufe zwischen den beiden Stufen abzuwechseln und die alte Generation mit der doppelten Überlebensrate der jungen Generation zu bereinigen.

Bedenken hinsichtlich Feinabstimmung und Wartung

Die Diskussion auf dem Summit verdeutlichte unterschiedliche Ansätze bezüglich Konfiguration und Wartbarkeit. Die Kernentwickler Donghee Na und Pablo Galindo Salgado thematisierten öffentliche Konfigurations-APIs und Abstimmungen zur Laufzeit, um Blockaden bei Upgrades zu vermeiden und Spezialfälle abzufangen. Demgegenüber äußerten sich Shannon und Gregory P. Smith zurückhaltend gegenüber Konfigurationsoptionen nach JVM-Vorbild oder der Unterstützung mehrerer Collector-Implementierungen. Sie gaben zu bedenken, dass öffentliche Tuning-Schnittstellen spätere interne Laufzeitoptimierungen einschränken und den Wartungsaufwand erhöhen können.

Auf Fragen zu potenziell nebeneinander laufenden oder sperrfreien Garbage Collectoren wies Shannon darauf hin, dass C-Erweiterungen strukturelle Hürden für sperrfreie Designs darstellen, da diese direkt ohne Nachverfolgung durch die Laufzeitumgebung auf den Speicher zugreifen können.

KI-generierte redaktionelle Illustration; kein Dokumentarfoto.

Quelle: Garbage Collection: Generational? Incremental? Both! (Python Language Summit 2026)