JRuby: Kommende Projekte

Hallo Freunde! Ich melde mich zurück im Blogspace mit einem Update zum JRuby-Status und einigen spannenden Projekten, die wir in der zweiten Hälfte des Jahres 2024 vorhaben. Lasst uns loslegen!

Ein neuer Weg

Wie ich im Juli im JRuby-Blog gepostet habe, ist die Unterstützung von JRuby durch Red Hat nach zwölf spannenden Jahren zu Ende gegangen. Es ist schwer, nach so vielen Jahren der bedingungslosen Unterstützung etwas anderes als Dankbarkeit zu empfinden, aber dieser Übergang hat neue Herausforderungen und Möglichkeiten für meine Arbeit an JRuby und JVM-Sprachen mit sich gebracht.

In den zwei Monaten seither haben meine Frau und Geschäftspartnerin Sondra und ich unser neues Unternehmen Headius Enterprises aufgebaut und JRuby-Benutzer für unser Basisangebot “Pro” kommerzieller JRuby-Support angemeldet. Wir haben demnächst eine mittlere “Experten”-Stufe mit Funktionen wie garantierten Bug-Reaktionszeiten, Zugang zum privaten Headius Slack und einem monatlichen Pool von “Finde, behebe und füge hinzu”-Entwicklungsstunden. Dies ist nach wie vor ein Lernprozess; nach fast 20 Jahren, in denen jemand anderes für die Entwicklung von JRuby bezahlt hat, muss ich es nun selbst finanzieren. Glücklicherweise haben wir ein solides Interesse von den vielen JRuby-Benutzern da draußen festgestellt. Vielleicht sind Sie einer von ihnen?

Über meine [GitHub-Sponsorenseite] (https://github.com/sponsors/headius) nehme ich auch Patenschaften von Einzelpersonen und Organisationen an. Die Finanzierung der OSS-Arbeit durch Sponsorenspenden ist eine Herausforderung, wenn man die tatsächlichen Kosten für die Entwicklung und die Selbstwartung bedenkt, aber wir sind dankbar für die Spenden, die wir bisher erhalten haben. Ein paar Einzelpersonen, die regelmäßig größere Spenden leisten, verdienen es, hier erwähnt zu werden: Shopify, Gautam Rege, Mark Triggs und BEESCM. Wenn Sie daran interessiert sind, JRuby am Laufen zu halten, sollten Sie sponsor my work noch heute unterstützen!

Die Zukunft von JRuby ist nicht in Frage gestellt (ich werde daran arbeiten, egal was passiert), aber ich schätze, dass ich etwa zwei Jahre Zeit habe, um dieses neue Projekt zum Laufen zu bringen. Je früher Sie mithelfen oder sich anmelden, desto wahrscheinlicher ist es, dass ich garantieren kann, dass die JRuby-Arbeit in Vollzeit fortgesetzt wird!

Beschleunigung der JRuby-Entwicklung

Zusammen mit den großen Änderungen bei der Finanzierung in diesem Jahr gibt es auch einige größere technische Veränderungen bei JRuby selbst.

Wir arbeiten derzeit an JRuby 10, dem nächsten großen Schritt nach der Veröffentlichung von JRuby 9000 (9.0.0.0) im Jahr 2015. Und Junge, was für ein Sprung das sein wird:

Ruby-Unterstützung auf 3.4 aktualisiert

Der größte Schritt für JRuby wird ein Sprung von der aktuellen Unterstützung für Ruby 3.1 (in der JRuby 9.4 Serie) bis hin zu Ruby 3.4 sein, das Ende 2024 erscheinen wird. Die Kompatibilität mit dieser neuen Version sieht schon jetzt gut aus, also werden wir die nächsten Monate damit verbringen, diese Unterstützung zu stabilisieren. Erwarten Sie eine JRuby 10 Version mit Ruby 3.4 Kompatibilität um das neue Jahr herum.

Java-Plattform-Update

Die minimale Java-Version, die für die Ausführung von JRuby erforderlich ist, wird entweder auf Java 17 oder Java 21 aktualisiert. Die JRuby 9000 (9.x) Serie wird Java 8 noch bis mindestens Ende 2025 unterstützen. Die Beibehaltung der Unterstützung für eine so alte Java-Version bedeutete, dass wir die Vorteile von fast zehn Jahren an Verbesserungen der Java-Sprache, der Kernbibliotheken des JDK und der JVM-Funktionen nicht einfach nutzen konnten. Es ist an der Zeit, einen großen Sprung zu modernen JDK-Versionen zu machen.

Optimierungsarbeiten

Da die Kompatibilität aufgeholt hat und der Java-Versionssprung im Gange ist, erkunden wir auch Optimierungen, die wir jahrelang auf Sparflamme gehalten haben. JRuby hat sich immer zuerst auf die Kompatibilität konzentriert, wobei Sprachaktualisierungen und Fehlerbehebungen für unsere Benutzer Vorrang hatten, und die Optimierungsarbeit wurde manchmal zurückgestellt. Viele Formen von Methodenaufrufen sind derzeit nicht gut optimiert (z.B. Superaufrufe und verfeinerte Aufrufe), Blockkonstruktion und Dispatch haben viel Raum für Verbesserungen, und wir können mehr tun, um invokedynamic zu nutzen, als wir es heute tun. Es wird Spaß machen, zu sehen, wie weit wir die Leistung von JRuby auf modernen JVMs steigern können, und ich habe bereits mit einigen dieser Arbeiten für JRuby 10 begonnen.

Übergang zur Finanzierung durch die Gemeinschaft und die Wirtschaft

Ich hoffe auch, dass die Änderungen in der Finanzierung von JRuby uns mehr Spielraum geben, um Community-Mitglieder einzustellen und direkt mit den Nutzern zu arbeiten… etwas, das als Angestellte eines großen Firmensponsors nur schwer möglich war. Es ist eine sehr aufregende Zeit!

JVM-Funktionen der nächsten Generation

Wir erforschen auch die breite Palette an erstaunlichen Funktionen, die für moderne JVMs entwickelt werden. Die meisten dieser Projekte wurden auf dem letzten [JVM Language Summit] (https://openjdk.org/projects/mlvm/jvmlangsummit/) ausführlich behandelt, wo ich auch einen Vortrag über “20 Years of JRuby” hielt. In den nächsten Blog-Beiträgen werde ich die JRuby-Integration im Detail besprechen, aber hier schon einmal eine Auswahl der Projekte, die ich mir ansehe:

Projekt CRaC - Checkpoint und Wiederherstellung für die JVM

JRuby hatte schon immer mit [langen Startzeiten] (http://blog.headius.com/2019/09/jruby-startup-time-exploration.html) zu kämpfen, und trotz unserer besten Bemühungen bleibt es ein schwer zu lösendes Problem auf bestehenden JVMs. Aber das könnte sich jetzt ändern.

Das Projekt CRaC (Coordinated Restore at Checkpoint) nutzt eine Linux-Funktion namens CRIU (Checkpoint and Restore in Userspace), um eine JVM vorzustarten und ein Abbild des Prozesses für künftige Ausführungen zu erstellen. Sobald Sie einen dieser “Checkpoints” erfasst haben, können Sie für zukünftige Befehle zum selben Punkt zurückkehren und direkt zur Ausführung Ihres Codes übergehen.

Wir werden CRaC in JRuby vollständig unterstützen, und ich werde bald eine Reihe von Beiträgen veröffentlichen, die zeigen, wie JRuby-Benutzer davon profitieren werden.

Projekt Leyden - Vorausschauendes Booten und Optimierung von JVM-Anwendungen

Ein ähnliches Projekt ist [Project Leyden] (https://openjdk.org/projects/leyden/), das sich ebenfalls um die Verbesserung der Startzeit bemüht. Anstatt jedoch eine Linux-spezifische Funktion wie CRaC zu verwenden, nutzt Leyden aggressives AOT-Booting (AOT = ahead of time), Profilerstellung und JIT, um zukünftigen Aufrufen zu helfen, schneller zu optimiertem Code zu gelangen. Während CRaC (größtenteils) auf Linux-ähnliche Umgebungen beschränkt sein wird, wird Leyden auf allen Plattformen verfügbar sein.

Wir haben bereits gute Ergebnisse in frühen JRuby on Leyden-Experimenten gesehen und werden mehr veröffentlichen, wenn sich das Projekt weiterentwickelt.

Projekt Loom - Virtuelles Threading für die JVM

Das [Projekt Loom] (https://openjdk.org/projects/loom/), das offiziell Teil von Java 21 ist, ermöglicht es uns, “virtuelle Threads” zu verwenden, um die “Fasern” von Ruby auf Tausende von gleichzeitigen Instanzen zu skalieren. Wir werden weiterhin mit den Loom-Ingenieuren zusammenarbeiten, um die Leistung der faserübergreifenden Kommunikation zu verbessern, die strukturierte Gleichzeitigkeit für asynchrone IO-Frameworks zu optimieren und die Speicheranforderungen für kleine, kurzlebige Fasern zu reduzieren. Nach der Anlaufzeit war die skalierbare Faserunterstützung eine der schwierigsten Herausforderungen für JRuby. Wir haben endlich eine hervorragende Lösung gefunden, und ich werde in den kommenden Wochen über unsere Arbeit bloggen.

Projekt Panama - Fremde Funktions- und Speicherschnittstelle für die JVM

JRuby hat immer die Grenzen der JVM erweitert, und um das Ruby-Ökosystem besser zu unterstützen, bedeutete das die Integration mit nativen Bibliotheken. Die [Ruby C Extension API] (https://docs.ruby-lang.org/en/master/extension_rdoc.html) ist zu invasiv und schwer zu unterstützen, also brauchten wir einen alternativen Weg, um C-Bibliotheken für die Verwendung aus Ruby-Code zu binden. Anstatt für jeden Fall JNI-Wrapper (Java Native Interface) zu entwickeln, haben wir dazu beigetragen, die Verwendung von Ruby FFI (Foreign Function Interface) zu popularisieren, um programmatisch native Funktionen zu laden und zu binden und den nativen Speicher zu verwalten.

Mit [Projekt Panama] (https://openjdk.org/projects/panama/) unterstützt das JDK nun direkt diese Bemühungen. Panama bringt drei Funktionen, die die Leistung, Skalierbarkeit und Benutzerfreundlichkeit der FFI-Schnittstellen von JRuby verbessern werden:

• Schnelle, JIT-unterstützte Aufrufe fremder Funktionen werden die Nutzung nativer Bibliotheken in vielerlei Hinsicht beschleunigen.
• Native Speicherverwaltungs-APIs werden die Zuweisung, Änderung, gemeinsame Nutzung und Verwaltung von nativem Speicher kostengünstig und effizient machen. Neben der Möglichkeit, besser mit nativen Funktionen zu interagieren, wird dies offizielle Unterstützung für Off-Heap-Daten bieten und die Leistung in Fällen verbessern, in denen keine vollständige GC-Unterstützung erforderlich ist.
• Code-Generierungs-Tools wie jextract werden es einfacher machen, sowohl Java- als auch Ruby-basierte FFI-Bindungen an native Bibliotheken zu erstellen. Letztendlich werden Sie Ihre JRuby-Installation einfach auf Header-Dateien richten, und der Bindungscode wird auf magische Weise erscheinen.

Wir haben bereits Hilfe von den OpenJDK-Entwicklern bei Oracle angenommen, um unser bestehendes FFI-Backend, JNR (Java Native Runtime), auf volle Panama-Unterstützung aufzurüsten. Erwarten Sie, dass Sie bald mehrere Beiträge über diese Arbeit sehen werden.

Projekt Babylon - Ein Code- und Übersetzungsmodell für JVM und darüber hinaus

Das [Projekt Babylon] (https://openjdk.org/projects/babylon/) will endlich eine Antwort auf die Herausforderungen geben, die sich bei der Übertragung von JVM-Bytecode-basierten Anwendungen und Bibliotheken auf alternative Plattformen wie SQL-Datenbanken, GPUs und maschinelle Lernmodelle stellen. Babylon führt das Konzept eines “Code-Modells” ein, das eine strukturiertere Darstellung von Code bietet, der entweder in JVM-Bytecode oder andere Sprachen wie CUDA und OpenCL übersetzt werden kann.

Das Potenzial von Java liegt auf der Hand: Schreiben Sie einfachen Java-Code, übersetzen Sie ihn in Ihr bevorzugtes GPU-Backend, und nutzen Sie die Vorteile massiv-paralleler Berechnungen. Das Potenzial für JRuby ist sogar noch aufregender: Was wäre, wenn man numerische Algorithmen in Ruby schreiben und sie direkt auf dem Grafikprozessor Tausende Male schneller ausführen könnte? Das ist mit JRuby und Babylon eine echte Möglichkeit, und ich freue mich darauf, sie zu verwirklichen.

Projekt Valhalla - Werttypen und verifizierte Generika

Wenn es um die Bewältigung schwieriger Probleme auf der JVM geht, kann [Project Valhalla] (https://openjdk.org/projects/valhalla/) den Preis gewinnen. Das 2014 gestartete Projekt Valhalla zielt darauf ab, der JVM endlich Unterstützung für die Stack-Allokation (über Werttypen) und reified generics (effiziente Darstellung von primitiven Werten in einer Objektwelt) zu bieten. Für JRuby wird dies mehrere große Verbesserungen bedeuten:

• Verringerung der Kosten für numerische Box-Objekte: In Ruby sind auch Zahlen Objekte, und JRuby weist den meisten “primitiven” numerischen Werten ein Objekt zu. In Zukunft werden wir in der Lage sein, Wertetypen zu verwenden, um diese primitiven Werte zu repräsentieren und so den Objekt-Overhead zu vermeiden, ohne Ruby-Features zu beeinträchtigen (oder auf anfällige Optimierungen wie Escape Analysis zu setzen).
• Günstigere Datenstrukturen für Ruby-Laufzeitfunktionen: Rubys Blöcke können Variablen aus der sie umgebenden Methode erfassen, und ohne JVM-Unterstützung für die direkte Änderung von Variablen auf dem Stack sind wir gezwungen, in diesen Fällen ein Heap-Objekt zuzuweisen. Wertetypen werden es uns leichter machen, den erfassten Zustand an die Blockausführung weiterzugeben, und können eine große Quelle von Speicherdruck für JRuby-Anwendungen beseitigen.
• Effizientere Sammlungen von “primitiven” Werten: Zusammen mit boxed primitives kommen Sammlungen von boxed primitives. Indem wir in der Lage sind, primitive Werte in objektbasierte Sammlungen zu reifizieren, haben wir eine kompaktere Darstellung von primitiven Werten in Arrays und Hashes.

Wir sind zuversichtlich, dass das Projekt Walhalla endlich eine der schwierigsten Herausforderungen für JRuby lösen wird: Wie kann man alles wie ein Objekt aussehen lassen, ohne die Kosten für die Verwaltung all dieser Objekte?

Die Zukunft von JRuby ist aufregend!

Dies ist nur ein Vorgeschmack auf die Pläne für JRuby im Jahr 2024, 2025 und darüber hinaus! Die Entwicklung von OpenJDK war noch nie so schnell und aufregend wie heute, und es gibt noch mehr Projekte am Horizont, die es einfacher machen, Nicht-Java-Sprachen auf der JVM zu unterstützen. Achten Sie an dieser Stelle auf meine kommenden Beiträge zu CRaC, Leyden, Loom, Panama, Babylon, Valhalla und mehr, und wenn Sie eine JRuby-Anwendung haben, die professionelle JRuby-Unterstützung benötigt, oder Ihre Organisation meine Arbeit sponsern möchte, nehmen Sie bitte Kontakt auf!

Beteiligen Sie sich an der Unterhaltung auf Reddit

Original-Text (http://blog.headius.com/2024/09/jruby-upcoming-projects-september-2024.html)