Ruby ist eine bewährte Programmiersprache, die bei Entwicklern wegen ihrer Einfachheit und Ausdrucksstärke beliebt ist. In jüngster Zeit rücken Ractors, ein Modell für parallele Ausführung in Ruby, immer stärker ins Zentrum des Interesses. Sie sollen ermöglichen, Threads effizienter und vor allem sicherer parallel auszuführen. Trotz ihres Potenzials stehen Ractors jedoch noch vor einigen großen Herausforderungen, die verhindern, dass sie bisher in vollem Umfang produktiv einsetzbar sind. Eine Hauptursache liegt in der Art und Weise, wie Ruby interne Mechanismen wie die Object_id-Methode implementiert, die zu unerwünschten Synchronisationseffekten und damit zu Leistungseinbußen führen.
Das Verständnis dieser Problematik gibt nicht nur Einblicke in Fortschritte der Ruby-Entwicklung, sondern zeigt auch auf, wie moderne Laufzeitumgebungen mit parallelen Systemen umgehen und welche Lösungsansätze es gibt, um Zukunftstechnologien wie Ractors zu perfektionieren. Seit der Einführung von Ractors in Ruby 3.0 verfolgt das Entwicklerteam das Ziel, parallele Verarbeitung ohne die üblichen Fallen von Thread-basiertem Programmieren zu ermöglichen. Ractors isolieren Ausführungskontexte voneinander, sodass Daten nicht direkt geteilt werden. Stattdessen kommunizieren sie über Nachrichten.
Trotzdem zeigen sich in der Realität viele Limitierungen, beispielweise durch globale Sperren im Ruby-Interpreter. Diese sogenannten Global VM Locks (GVL) verhindern, dass kritische Bereiche gleichzeitig von mehreren Ractors bearbeitet werden, was die Vorteile der Parallelisierung stark einschränkt. Ein konkretes Beispiel für einen solchen Engpass war lange Zeit die interne fstring_table, eine große Hash-Tabelle, die zur Vermeidung von Duplikaten bei Strings dient. Solange diese Tabelle von einem Ractor verändert wurde, mussten andere Ractors warten, was die Parallelperformance stark beeinträchtigte. Die jüngsten Arbeiten von John Hawthorn, der diese Tabelle durch eine lockfreie Hash-Set-Implementierung ersetzte, machen deutlich, wie man solche Flaschenhälse entschärfen kann.
Benchmarks zeigten, dass die Ausführung der JSON-Verarbeitung plötzlich doppelt so schnell wurde im Vergleich zur seriellen Variante – ein Erfolge, der noch vor einigen Monaten kaum denkbar war. Jedoch gibt es neben der fstring_table noch weitere nicht-offensichtliche Kontentionen, die die Leistung von Ractors drosseln. Eine davon ist die Object_id-Methode. Trotz des scheinbar simplen Zweckes, die eindeutige Identifikation eines Objekts zu liefern, verbirgt sich dahinter ein komplexer Mechanismus mit hohen Synchronisationskosten. Um die Gründe hierfür zu verstehen, lohnt sich ein Blick in die Historie und die Architektur von Ruby.
Historisch basierte die Object_id auf der Speicheradresse des Objekts, die teilweise durch eine einfache mathematische Operation transformiert wurde. Diese Umsetzung ist hoch performant, da keine weiteren Datenstrukturen konsultiert werden mussten. Allerdings führte dieses Prinzip zu einem gravierenden Problem: Objekte können vom Garbage Collector (GC) verschoben werden oder freigegeben und der Speicher für neue Objekte wiederverwendet werden. Eine feste Referenz auf die Adresse konnte somit nicht gewährleisten, dass der zurückgegebene Wert einem bestimmten Objekt tatsächlich dauerhaft zugeordnet ist. Dieses Risiko von Kollisionen oder false positives macht den Wert von Object_id in komplizierteren Szenarien fragwürdig.
Seit Ruby 2.7 wurde deshalb der Object_id-Mechanismus grundlegend geändert. Heute verfolgt Ruby einen Ansatz, bei dem interne Hash-Tabellen zur Zuordnung von Objekten und deren IDs verwendet werden. Bei der ersten Abfrage wird einem Objekt eine eindeutige ID zugewiesen, die dann in zwei Hash-Tabellen festgehalten wird: eine, die das Objekt auf seine ID abbildet, sowie eine umgekehrte für die Rückwärtsauflösung. Dieses Verfahren garantiert Stabilität und die Korrektheit von Object_id, auch wenn Objekte verschoben werden oder der Speicher innerhalb des Heaps dynamisch verändert wird.
Allerdings hat diese Umstellung einen hohen Preis: Der Zugriff auf Object_id ist jetzt mit einem Lookup in einer globalen, gemeinsamen Hash-Tabelle verbunden, was besonders in einer parallelen Umgebung zu Sperren führt. Hierbei muss der Ruby Virtual Machine Lock gehalten werden, um Konsistenz der Datenstrukturen zwischen den Ractors sicherzustellen. In Folge dessen wird Object_id – trotz ihrer scheinbaren Einfachheit – zu einem kritischen Engpass für die Parallelperformance bei der Ausführung von Ruby-Code mit Ractors. Interessanterweise wird die Object_id-Methode nicht nur explizit vom Entwicklercode aufgerufen, sondern insbesondere indirekt über das Hash-Verfahren vieler Objekte. Im Ruby-Kern etwa verwendet die Standardimplementierung von Object#hash die Object_id als Grundlage.
Das bedeutet, bei vielen Operationen wie der Prüfung von Hash-Containern, Caches oder auch Identity-Checks fällt jedes Mal die Sperrung der Virtual Machine an. Das schränkt die Skalierbarkeit und Effizienz von Parallelcode erheblich ein. Ein vielversprechender Ansatz, um diese Sperrproblematik zu entschärfen, ist es, die Object_id künftig direkt im Objekt zu speichern. Die Idee ist, die Object_id als Inline-Daten im Objekt selbst abzulegen, genau wie Instanzvariablen. Dadurch wäre kein Hash-Lookup mehr erforderlich und der Zugriff könnte nahezu ohne aufwendige Synchronisation erfolgen.
Voraussetzung dafür ist, dass man über das Objekt und dessen interne Struktur direkt verfügt, um die ID sicher und konsistent zu speichern und abzurufen. Seit Ruby 3.2 verwendet die Runtime sogenannte Shapes, die die Form von Objekten beschreiben, vor allem wie Instanzvariablen in den meist fixen Speicherbereichen der Objekte organisiert sind. Diese Shapes sind hierarchisch und erlauben effiziente Speicherlayouts. Durch die Erstellung eines speziellen SHAPE_OBJ_ID kann der Ruby-Interpreter zukünftig Object_ids direkt als zusätzlichen internen Slot in den Objekten vorhalten.
Somit wird beim erstmaligen Zugriff auf Object_id eine einmalige Initialisierung notwendig, alle Nachfolgezugriffe sind jedoch ohne weitere Sperren möglich. Die Umsetzung dieses Konzepts ist allerdings nicht trivial. Einige Objekttypen wie Klassen und Module verwalten Instanzvariablen anders als Normalobjekte und verfügen oft über separate interne Speicherblöcke. Darüber hinaus gibt es sogenannte generische Objekte, die ihre Instanzvariablen nicht inline speichern, sondern in globalen oder pro-Objekt-Hash-Tabellen. Für diese Spezialfälle bleibt es eine Herausforderung, Object_id effizient und ohne nennenswerte Synchronisationskosten zu implementieren.
Ein weiteres Problem ergibt sich daraus, dass Shapes und deren Knoten (insbesondere für neue Objekt-Layouts) zwar im Alltag weitgehend immutable sind und lock-frei abgerufen werden können, das Hinzufügen von neuen Kanten oder das Erstellen neuer Shapes aber momentan noch Synchronisation innerhalb der VM erfordert. Hier sind weitere Optimierungen nötig, um wirklich komplett lock-freien Zugriff gewährleisten zu können. Die Vorteile einer erfolgreichen Umsetzung sind für Ractors beträchtlich. Eliminierte Contention-Punkte bei häufig genutzten Funktionen wie Object_id können die Parallelperformance deutlich steigern und so die Vorteile von Ractors in der Praxis realisieren. Schon kleinere Verbesserungen summieren sich bei Anwendungen wie Webservern, Analyse- und Hintergrundprozessen, bei denen viele kleine Objekte intensiv verwaltet und geprüft werden müssen.
Die Arbeit an dieser Problematik zeigt exemplarisch, wie tiefgreifend infrastrukturelle Entscheidungen und interne Implementierungen den Gesamtdurchsatz und die Skalierbarkeit einer Sprache beeinflussen. Während viele Entwickler Ractors wegen der potenziellen Parallelität schätzen, verdeutlicht das Beispiel von Object_id, dass selbst kleine, scheinbar unbedeutende Methoden zum Nadelöhr werden können. Parallel zur Optimierung von Object_id wird an anderen Bereichen gearbeitet. So müssen auch Symboltabellen, Methodentabellen und weitere globale Datenstrukturen für eine bessere Parallelität redesigniert werden, häufig in Richtung lockfreie oder zumindest weniger konkurrierende Datenstrukturen. Dieser Evolutionsprozess ist essenziell für die Zukunft von Ruby als performante Sprache in Multi-Core-Umgebungen.
Ein bedeutender Nebenaspekt betrifft auch die Funktion ObjectSpace._id2ref. Diese Methode wurde in früheren Ruby-Versionen kaum genutzt und ist mit Sicherheitsproblemen und potenziellen Memory-Leaks behaftet. Im Zuge der Arbeiten an Object_id wird über eine offizielle Deklaration als veraltet diskutiert, die ihre Nutzung in der Praxis zurückdrängen soll. So kann noch weiter die interne Komplexität reduziert und die Performance gesteigert werden.
Insgesamt ist die Entwicklung von Ractors ein faszinierender Einblick in moderne Interpreterarchitektur. Sie zeigt, dass Parallelisierung nicht nur die Einführung neuer Sprachfeatures bedeutet, sondern tiefgreifende Änderungen in Speicherverwaltung, Synchronisation und internen Datenstrukturen erfordert. Die Arbeit an der Object_id-Optimierung ist dabei ein besonders anschauliches Beispiel für die Herausforderungen und Chancen in diesem Bereich. Die Zukunft für Ractors in Ruby sieht vielversprechend aus. Mit der Entfernung von globalen Sperren und der Schaffung lockfreier Datenstrukturen kann eine echte Parallelisierungsrevolution gelingen, die Ruby noch leistungsfähiger und konkurrenzfähiger macht.
