Wir haben kürzlich darüber geschrieben, welche Tricks Alibaba unternommen hat, um das Leben mit OpenJDK akzeptabler zu machen. Es gab Kommentare wie "Es stellt sich heraus, dass die Chinesen, während wir unter gewöhnlichem Java leiden, bereits ihr eigenes Special gemacht haben." Alibaba ist natürlich beeindruckend - aber Russland hat auch seine eigenen grundlegenden Projekte, in denen auch „spezielles Java“ hergestellt wird.
In Nowosibirsk stellen sie seit 18 Jahren ihre eigene JVM her , die völlig unabhängig und gefragt weit über die Grenzen Russlands hinaus geschrieben wurde. Es ist nicht nur eine Art HotSpot-Gabel, die das Gleiche tut, sondern auch ein bisschen besser. Excelsior JET ist eine Suite von Lösungen, mit denen Sie in Bezug auf die AOT-Kompilierung völlig andere Dinge tun können. "Pff, AOT ist in GraalVM", kann man sagen. Aber GraalVM ist immer noch eine sehr explorative Sache, und JET ist eine bewährte Lösung für den Einsatz in der Produktion.
Dies ist ein Interview mit einem der Entwickler von Excelsior JET. Ich hoffe, es wird besonders interessant für alle, die neue Dinge entdecken möchten, die mit Java gemacht werden können. Oder Menschen, die sich für das Leben von JVM-Ingenieuren interessieren und selbst daran teilnehmen möchten.
Im Herbst flog ich zu einer der Java-Konferenzen in Nowosibirsk. Wir setzten uns mit Ivan Uglyansky dbg_nsk und Nikita Lipsky pjBooms (einem der Entwickler von JET) zusammen und nahmen dieses Interview auf. Ivan beschäftigt sich mit JET-Laufzeit: GC, Laden von Klassen, Multithreading-Unterstützung, Profilerstellung, Plugin für GDB. Nikita - einer der Initiatoren des JET-Projekts - war an der Forschung und Entwicklung fast aller Produktkomponenten vom Kernel bis zu den Produkteigenschaften beteiligt - OSGi auf JVM-Ebene, Java Runtime Slim Down (Java-Module in JET waren bereits 2007), zwei Bytecode-Verifizierer, Unterstützung Frühlingsstiefel und so weiter.
Oleg Chirukhin: Können Sie unwissenden Menschen von Ihrem Produkt erzählen?
Nikita Lipsky: Es ist natürlich überraschend, dass wir seit 18 Jahren auf dem Markt sind und nicht viel wissen. Wir machen eine ungewöhnliche JVM. Ungewöhnlich beim Wetten auf die AOT-Zusammenstellung, d.h. Wir versuchen, Java-Bytecode im Voraus in Maschinencode zu kompilieren.
Die Idee des Projekts war zunächst, Java schnell zu machen. Produktivität ist das, womit wir auf den Markt gegangen sind. Und während wir gingen, wurde Java immer noch interpretiert, und die statische Kompilierung in Maschinencode versprach, die Java-Leistung nicht einmal zeitweise, sondern um Größenordnungen zu verbessern. Aber selbst in Gegenwart von JIT verbrauchen Sie zur Laufzeit keine Ressourcen für die Kompilierung, wenn Sie alles im Voraus kompilieren. Auf diese Weise können Sie mehr Zeit und Speicher aufwenden und schließlich optimierten Code erhalten.
Ein Nebeneffekt der statischen Bytecode-Kompilierung ist neben der Leistung der Schutz von Java-Anwendungen vor Dekompilierung. Da nach der Kompilierung kein Bytecode mehr vorhanden ist, bleibt nur der Maschinencode übrig. Es ist viel schwieriger, in Quellcode zu dekompilieren als Java-Bytecode. In der Tat unmöglich. Das heißt, es kann zerlegt werden, aber Sie werden keine Quellcodes gebären. Java-Quellcode kann jedoch problemlos aus Bytecode bis hin zu Variablennamen generiert werden. Dafür gibt es viele Tools.
Außerdem wurde früher angenommen, dass Java auf allen Computern installiert ist. Sie verteilen Ihre Java-Anwendungen in Form von Bytecode und sie werden überall gleich ausgeführt. Aber in Wirklichkeit war nicht alles so gut, weil einer ein Java hat, der andere ein anderes. Wenn Sie das Programm in Form von Bytecode verteilen, können daher alle möglichen Überraschungen auftreten, angefangen mit der Tatsache, dass der Benutzer Ihr Programm einfach nicht starten konnte, bis hin zu einem seltsamen Verhalten, das Sie nicht in sich selbst zeigen konnten. Unser Produkt hatte immer den Vorteil, dass Sie Ihre Java-Anwendung einfach als native Anwendung vertreiben. Sie haben keine Abhängigkeit von der Laufzeit, die der Benutzer hat (oder nicht wert ist).
Ivan Uglyansky: Im Allgemeinen muss Java nicht installiert sein.
Oleg: Es bleibt eine Abhängigkeit vom Betriebssystem, oder?
Nikita: Richtig. Viele kritisieren, dass Ihr Slogan „Einmal schreiben - überall ausführen“ nicht mehr funktioniert, wenn Sie in nativen Code kompilieren. Aber das ist nicht so. In meinen Berichten erzähle ich regelmäßig, dass „einmal schreiben“ wie „einmal schreiben“ und nicht „einmal bauen“ klingt. Das heißt, Sie können Ihre Java-Anwendung auf jeder Plattform erstellen und sie funktioniert überall.
Oleg: Direkt überall, überall?
Nikita: Wo immer unterstützt. Wir haben eine Java-kompatible Lösung. Wenn Sie in Java schreiben, funktioniert es dort, wo Java funktioniert. Und wenn Sie das von uns kompilierte verwenden, wo wir es unterstützen - Windows, Linux, Mac, x86, amd64, ARM32. Wenn wir dies jedoch nicht unterstützen, können Sie weiterhin normales Java für Ihre Anwendungen verwenden, dh die Portabilität Ihrer Java-Anwendungen in diesem Sinne leidet nicht.
Oleg: Gibt es solche Designs, die auf verschiedenen Plattformen unterschiedlich implementiert sind? Teile der Plattform, die nicht vollständig implementiert sind, einige Standardbibliotheken.
Ivan: Es passiert, aber es ist nicht JET-spezifisch. Sie können sich beispielsweise die AsynchronousFileChannel-Implementierung im JDK selbst ansehen. Sie ist unter verschiedenen Windows- und Posix-Versionen völlig unterschiedlich, was logisch ist. Einige Dinge sind nur auf bestimmten Plattformen implementiert, Unterstützung für SCTP (siehe sun.nio.ch.sctp.SctpChannelImpl unter Windows) und SDP (siehe sun.net.sdp.SdpSupport). Darin besteht kein besonderer Widerspruch, aber es stellt sich wirklich heraus, dass „Einmal schreiben, irgendwo laufen“ nicht ganz richtig ist.
Wenn man speziell über die Implementierung der JVM spricht, kann der Unterschied unter verschiedenen Betriebssystemen natürlich sehr groß sein. Was ist die Tatsache, dass Sie unter OS X im Hauptthread die Cocoa-Ereignisschleife ausführen müssen, damit sich der Start dort von den anderen unterscheidet.
Nikita: Trotzdem sieht von außen alles für den Benutzer fast gleich aus und funktioniert fast gleich.
Oleg: Was ist mit der Aufführung? Ist es auf allen Plattformen gleich?
Nikita: Es gibt einen Unterschied. Ein Linux-Dateisystem funktioniert beispielsweise besser und schneller als ein Windows-Dateisystem.
Oleg: Und Portierung zwischen Prozessoren?
Nikita: Das ist eine lustige Aktivität! Das ganze Team beginnt plötzlich zu portieren. Die Unterhaltung dauert normalerweise sechs Monate bis ein Jahr.
Oleg: Kommt es vor, dass ein Teil des Codes auf einer anderen Plattform langsamer wird?
Ivan: Das mag daran liegen, dass wir einfach keine Zeit hatten, eine Optimierung vorzunehmen oder anzupassen. Auf x86 hat es gut funktioniert, dann sind wir auf AMD64 umgestiegen und haben es einfach nicht geschafft, es anzupassen. Aus diesem Grund kann es langsamer sein.
Ein weiteres Leistungsbeispiel. ARM hat ein schwaches Speichermodell. Sie müssen dort viel mehr Barrieren setzen, damit alles richtig funktioniert. Wir hatten AMD64, einige Orte arbeiteten, denken, dann frei, weil dort das Speichermodell anders ist. Bei ARM müssen Sie mehr Barrieren setzen, dies ist jedoch nicht kostenlos.
Oleg: Lassen Sie uns jetzt über das heiße Thema sprechen - "Java auf eingebetteten Geräten".
Nehmen wir an, ich mache ein Flugzeug, das mit Kontrolle auf einem Raspberry Pi fliegt. Was sind einige typische Probleme, die eine Person hat, wenn sie dies tut? Und wie kann JET und allgemein die AOT-Kompilierung in dieser Angelegenheit helfen?
Nikita: Das Flugzeug auf dem Raspberry Pi ist natürlich ein interessantes Thema. Wir haben ARM32 gemacht und jetzt ist JET auf dem Raspberry Pi. Wir haben eine unbegrenzte Anzahl von Kunden für Embedded, aber es gibt nicht so viele, die über ihre "typischen" Probleme sprechen. Obwohl sie einige Probleme mit Java haben, ist es nicht schwer zu erraten.
Ivan: Was sind die Probleme mit Java auf dem Raspberry Pi? Es liegt ein Problem mit dem Speicherverbrauch vor. Wenn Sie es zu sehr brauchen, haben die Anwendung und die JVM Schwierigkeiten, auf dem armen Raspberry Pi zu leben. Darüber hinaus ist ein schneller Start auf eingebetteten Geräten wichtig, damit die Anwendung dort nicht zu lange beschleunigt. AOT löst diese beiden Probleme gut, daher arbeiten wir daran, die eingebettete Unterstützung zu verbessern. Insbesondere in Bezug auf den Raspberry Pi ist Bellsoft zu erwähnen, das sich jetzt aktiv mit HotSpot befasst. Dort ist normales Java vollständig vorhanden.
Nikita: Darüber hinaus gibt es auf eingebetteten Systemen nur wenige Ressourcen, und der JIT-Compiler kann nirgendwo bereitgestellt werden. Dementsprechend beschleunigt die AOT-Kompilierung selbst die Leistung.
Auch hier sind eingebettete Geräte über eine Batterie ohne Verbindung zum Netzwerk. Warum gibt es eine Batterie für den JIT-Compiler, wenn Sie alles im Voraus zusammenbauen können?
Oleg: Welche Funktionen haben Sie? Ich verstehe, dass JET ein sehr großes komplexes System mit einer Menge von allem ist. Sie haben eine AOT-Kompilierung, dh Sie können eine ausführbare Datei kompilieren. Was sonst? Über welche interessanten Komponenten sollte gesprochen werden?
Ivan: Wir haben eine Reihe von Funktionen in Bezug auf die Leistung.
Kürzlich habe ich über PGO gesprochen, unser relativ neues Feature. Wir haben einen integrierten Profiler direkt in der JVM sowie eine Reihe von Optimierungen, die auf dem gesammelten Profil basieren. Nach dem Neukompilieren basierend auf dem Profil erhalten wir häufig einen ernsthaften Leistungsschub. Tatsache ist, dass Leistungsinformationen zu unseren leistungsstarken statischen Analysen und Optimierungen hinzugefügt werden. Es ist ein leicht hybrider Ansatz, das Beste aus der JIT- und AOT-Kompilierung herauszuholen.
Wir haben zwei wundervolle Funktionen für eine noch schnellere Startbeschleunigung. Das erste ist, wenn Sie sich die Reihenfolge ansehen, in der Speicherseiten anfänglich durchbohrt werden, überwachen Sie sie einfach und verknüpfen die ausführbare Datei entsprechend.
Nikita: Zweitens: Wenn Sie die ausführbare Datei starten, verstehen Sie, welche Speicherelemente abgerufen werden, und anstatt sie in beliebiger Reihenfolge abzurufen, rufen Sie sofort das gewünschte Element auf. Beschleunigt auch den Start erheblich.
Ivan: Dies sind einzelne Lebensmittelmerkmale.
Nikita: Der erste heißt Startup Optimizer und der zweite ist Startup Accelerator. Funktionen funktionieren anders. Um die erste zu verwenden, müssen Sie die Anwendung vor dem Kompilieren ausführen. Sie merkt sich, in welcher Reihenfolge der Code ausgeführt wurde. In der richtigen Reihenfolge wird dieser Code dann verknüpft. Und die zweite ist das Starten Ihrer Anwendung nach dem Kompilieren. Dann wissen wir bereits, was wohin und wohin gegangen ist, und danach durchbohren wir beim Start alles in der richtigen Reihenfolge.
Zusätzlich zu den leistungsbezogenen Funktionen gibt es eine Reihe von Produktfunktionen, die die Verwendung von JET komfortabler machen.
Zum Beispiel können wir beispielsweise Windows-Distributionen packen. Einmal - und bekam ein Windows-Installationsprogramm. Sie können Java-Anwendungen als echte native Anwendungen verteilen. Es gibt noch viel mehr. Beispielsweise gibt es ein solches Standardproblem bei AOT-Compilern und Java, wenn eine Anwendung ihre eigenen Klassenlader verwendet. Wenn Sie einen eigenen Klassenlader haben, ist nicht klar, welche Klassen wir AOT kompilieren werden? Denn dort kann die Logik der Auflösung zwischen Klassen alles sein. Dementsprechend funktioniert kein einziger Java AOT-Compiler außer unserem mit nicht standardmäßigen Klassenladern. Wir haben in AOT spezielle Unterstützung für einige Anwendungsklassen, in denen wir wissen, wie ihre benutzerdefinierten Loader funktionieren und wie Verknüpfungen zwischen Klassen aufgelöst werden. Zum Beispiel haben wir Unterstützung für Eclipse RCP und es gibt Clients, die Desktop-Anwendungen auf Eclipse RCP schreiben und mit uns kompilieren. Tomcat wird unterstützt, dort werden auch benutzerdefinierte Lader verwendet. Sie können mit uns Tomcat-Anwendungen kompilieren. Wir haben kürzlich eine sofort einsatzbereite Spring Boot JET-Version veröffentlicht.
Oleg: Welchen Server gibt es "unten"?
Nikita: Was auch immer du willst. Welche Spring Boot-Unterstützung funktioniert damit? Tomcat, Undertow, Jetty, Webflux.
Ivan: Hier muss erwähnt werden, dass wir für Jetty nicht die Unterstützung seiner benutzerdefinierten Klassenlader haben.
Nikita: Jetty verfügt als eigenständiger Webserver über einen benutzerdefinierten Klassenladeprogramm. Aber es gibt so etwas wie Jetty Embedded, das ohne benutzerdefinierte Lader funktionieren kann. Jetty Embedded läuft leise auf Excelsior JET. In Spring Boot funktioniert Jetty in der nächsten Version wie alle anderen von Spring Boot unterstützten Server.
Oleg: Tatsächlich ist die Benutzeroberfläche mit JET Javac und Java oder etwas anderes?
Ivan: Nein. Für den Benutzer haben wir verschiedene Möglichkeiten, JET zu verwenden. Erstens ist dies eine GUI, in der der Benutzer alle Funktionen durchstößt, danach eine Taste drückt und seine Anwendung kompiliert. Wenn er ein Installationsprogramm erstellen möchte, damit der Benutzer die Anwendung installieren kann, drückt er erneut auf die Schaltflächen. Dieser Ansatz ist jedoch etwas veraltet (GUIs wurden bereits 2003 entwickelt). Daher hat Nikita jetzt Plugins für Maven und Gradle entwickelt, die für moderne Benutzer viel praktischer und vertrauter sind.
Nikita: Ersetzen Sie sieben Zeilen in pom.xml oder build.gradle, sagen Sie mvn jet:build , und Sie haben einen Wurststab auf der Ausgabe.
Oleg: Und jetzt lieben alle Docker und Kubernetes sehr. Können Sie für sie bauen?
Nikita: Docker ist das nächste Thema. Wir haben einen solchen Parameter - Verpackung in Maven / Gradle-Plugins. Ich kann Verpackungsanwendungen für Docker hinzufügen.
Ivan: Das ist noch in Arbeit. Insgesamt haben wir jedoch versucht, JET-kompilierte Anwendungen auf Docker auszuführen.
Nikita: Es funktioniert. Ohne Java. Nacktes Linux, kleben Sie die JET-kompilierte Anwendung dort und es beginnt.
Oleg: Und mit der Verpackung des Dockers, was wird die Ausgabe sein? Einen Container oder eine ausführbare Datei mit den Händen in die Docker-Datei schieben?
Nikita: Jetzt schreiben Sie einfach eine JET-spezifische Docker-Datei - das sind drei Zeilen. Darüber hinaus funktioniert alles mit regulären Docker-Tools.
Ich spiele gerade mit Microservices. Ich kompiliere sie mit JET, führe sie aus, sie entdecken sich gegenseitig, kommunizieren. Die JVM musste dafür nichts unternehmen.
Oleg: Jetzt haben alle Arten von Cloud-Anbietern Dinge wie Amazon Lambda, Google Cloud Functions, gestartet. Kann ich es dort verwenden?
Nikita: Ich denke, wir müssen zu den Anbietern all dieser Dinge gehen und sagen, dass alle Ihre Lambdas schneller funktionieren, wenn Sie uns verwenden. Das ist aber immer noch nur eine Idee.
Oleg: Also werden sie wirklich schneller arbeiten!
Nikita: Ja, höchstwahrscheinlich muss mehr Arbeit in diese Richtung geleistet werden.
Oleg: Ich sehe ein Problem in der Lambda-Kompilierungszeit. Was ist Ihre Kompilierungszeit?
Ivan: Es existiert, und dies ist ein Problem, über das Benutzer gewöhnlicher JVMs mit JITs nicht nachdenken. Normalerweise funktioniert es schließlich, wie - ich habe die Anwendung gestartet (wenn auch zunächst langsam wegen der Kompilierung). Und hier kommt ein separater Schritt zum AOT-Kompilieren der gesamten Anwendung. Dies kann empfindlich sein, daher arbeiten wir daran, diese Phase zu beschleunigen. Zum Beispiel haben wir eine inkrementelle Neukompilierung, wenn nur die geänderten Teile der Anwendung neu kompiliert werden. Wir nennen es intelligente Neukompilierung. Wir haben das gerade in der letzten Jungfernperiode mit Nikita gemacht, wir waren gepaart.
Nikita: Es gibt bestimmte Probleme mit Java und mit der intelligenten Neukompilierung, zum Beispiel zirkuläre Abhängigkeiten innerhalb von Java-Anwendungen - sie sind überall.
Ivan: Es gibt dort viele ziemlich offensichtliche Probleme, bis Sie über diese Aufgabe nachdenken. Wenn Sie einen statischen AOT-Compiler haben, der verschiedene globale Optimierungen vornimmt, ist es nicht so einfach zu berechnen, was genau neu kompiliert werden muss. Sie müssen sich an all diese Optimierungen erinnern. Und Optimierungen können nicht trivial sein. Zum Beispiel könnten Sie alle möglichen komplexen Devirtualisierungen durchführen und etwas einbinden, von dem der Teufel weiß, wo. Wenn Sie einen Klassiker oder eine JAR geändert haben, bedeutet dies nicht, dass nur diese neu kompiliert werden muss und das war's. Nein, das ist alles viel verwirrender. Sie müssen alle vom Compiler vorgenommenen Optimierungen berechnen und speichern.
Nikita: Eigentlich das Gleiche tun wie JIT, wenn es eine Entscheidung über die Deoptimierung trifft, aber nur im AOT-Compiler. Nur bei der Lösung geht es nicht um Deoptimierung, sondern um Neukompilierung.
Oleg: Über die Geschwindigkeit der intelligenten Kompilierung. Wenn ich "Hallo Welt" nehme, kompiliere ich es und ändere die beiden Buchstaben im Wort "Hallo" ...
Nikita: Es kompiliert schnell.
Oleg: Ich meine, keine Minute?
Nikita: Sekunden.
Ivan: Aber es hängt immer noch davon ab, ob wir Plattformklassen in die ausführbare Datei aufnehmen.
Oleg: Und was ist ohne das möglich?
Nikita: Ja, standardmäßig ist unsere Plattform in mehrere DLLs unterteilt. Wir haben Jigsaw ganz am Anfang implementiert :-) Das heißt, wir haben vor sehr langer Zeit Java SE-Klassen für Komponenten gesägt, in ungefähr 90 Jahren.
Ivan: Der Punkt ist, dass unsere Laufzeit- und Plattformklassen - sie werden alle von uns vorkompiliert und ja - in DLLs unterteilt sind. Wenn Sie die von JET kompilierte Anwendung ausführen, werden die Laufzeit und die gesamte Plattform in Form dieser DLLs dargestellt. Das heißt, es sieht so aus: Sie nehmen "Hallo Welt", kompilieren, Sie kompilieren wirklich eine Klasse. Dies geschieht in wenigen Sekunden.
Nikita: In 4 Sekunden, wenn in der Welt; in ein paar Sekunden, wenn nicht in der globalen. "Global" ist, wenn Sie verknüpfen: Alle Plattformklassen, die zu nativem Code in einer großen ausführbaren Datei kompiliert wurden.
Oleg: Kann ich ein heißes Nachladen machen?
Nikita: Nein.
Oleg: Nein? Traurigkeit. Aber es wäre möglich, eine DLL zu generieren, sie erneut zu verknüpfen und dann ...
Nikita: Da wir JIT haben (übrigens ja, wir haben auch JIT!), Können Sie natürlich Codeteile laden, entladen und neu laden. Zum Beispiel befindet sich der gesamte Code, der über unsere JIT funktioniert, in derselben OSGI - Sie können ihn neu laden, wenn Sie möchten. Aber hier ist das Hot-Reload, das HotSpot hat. Wenn Sie im Debugger sitzen und den Code im laufenden Betrieb ändern, tun wir dies nicht. Dies ist ohne Leistungsverlust nicht möglich.
Oleg: In der Entwicklungsphase ist die Leistung nicht so wichtig.
Nikita: In der Entwicklungsphase verwenden Sie HotSpot und benötigen nichts anderes. Wir sind eine Java-kompatible Lösung. Wenn Sie HotSpot verwenden und beim Debuggen Hot Reload verwenden, ist alles in Ordnung. Debugging, kompiliertes JET und alles funktioniert wie bei HotSpot. Es sollte so sein. Normalerweise so. Wenn nicht, schreiben Sie an den Support, wir verstehen.
Oleg: Was ist mit dem Debuggen in JET? JVM TI? Wie viel wird alles unterstützt?
Ivan: Einer der Grundwerte bei der Verwendung von JET ist die Sicherheit. Benutzerdefinierter Code steht niemandem zur Verfügung. Weil alles in native kompiliert ist. Es gibt einige Widersprüche. Unterstützen wir JVM TI? Wenn wir unterstützen, bedeutet dies, dass jeder entwickelte Entwickler, der weiß, wie die JVM TI funktioniert, schnell auf alles zugreifen kann. Wir unterstützen JVM TI derzeit nicht.
Nikita: Dies ist eine optionale Spezifikation. Es wird möglicherweise von Plattformimplementierern unterstützt, möglicherweise nicht.
Ivan: Es gibt viele Gründe. Es ist optional und verletzt die Sicherheit, was bedeutet, dass Benutzer uns nicht „Danke“ sagen. Und sie ist drinnen und sehr HotSpot-spezifisch. Vor nicht allzu langer Zeit haben unsere Jungs die JVM TI als experimentelles Projekt unterstützt, sie haben ein bestimmtes Stadium erreicht, aber die ganze Zeit waren sie mit der Tatsache konfrontiert, dass es sehr auf HotSpot ausgerichtet war. Im Prinzip ist dies möglich, aber welche Geschäftsaufgabe wird gelöst?
Nikita: Nachdem Sie mit HotSpot Geld verdient haben, aber mit einem Jet kein Geld verdient haben, ist dies nicht Ihr Problem. Das ist unser Problem.
Oleg: Verstanden. Haben Sie zusätzliche Funktionen, die
nicht in HotSpot, aber haben Sie einen, und sie erfordern direkte Kontrolle? Was ich gerne debuggen würde, sortiere ich aus.
Nikita: Genau eine Funktion. Wir haben eine offizielle Erweiterung der Plattform namens Windows-Dienste, dh Sie können Java-Anwendungen in Form von echten Windows-Diensten kompilieren, die über Standard-Windows-Tools für Windows-Dienste usw. überwacht werden. In diesem Fall müssen Sie unsere eigene JAR abholen, um solche Anwendungen zu kompilieren.
Oleg: Das ist nicht das größte Problem.
Nikita: Die Schnittstelle ist für diese Dienste sehr einfach. Beim Debuggen verwenden Sie die Methoden zum Starten Ihrer eigenen Anwendung nicht als Windows-Dienst, sondern über main. Ich weiß nicht, ob eine Art dienstspezifisches Debugging erforderlich ist.
Oleg: Angenommen, ein neuer Entwickler, der zuvor für HotSpot gearbeitet hat, möchte etwas mit JET entwickeln. Muss er etwas lernen, etwas allgemein über das Leben oder über JET verstehen?
Ivan: Er muss sieben Zeilen in pom.xml kopieren, wenn Maven verwendet wird, dann jet: build ausführen und wenn JET auf dem Computer ist, wird die Java-Anwendung in eine ausführbare Datei kompiliert. Die Idee ist, dass es einfach ist, Sie nichts Besonderes tun, sondern es einfach nehmen, eine ausführbare Datei erhalten und fertig.
Nikita: Entweder kennen Sie die Befehlszeile, mit der Ihre Anwendung gestartet wird, oder Sie fügen diese Befehlszeile in unsere GUI ein, um es herauszufinden. Sie geben den Befehl build ein, Sie erhalten die ausführbare Datei, das ist alles.
Ivan: Es ist sehr einfach, du musst nichts Neues erfinden. Wie der Hotspot AOT funktioniert, haben Sie selbst im Bericht gezeigt, dass Sie eine Liste aller Methoden in eine Datei abrufen, sie durchsuchen und transformieren müssen - wir müssen so etwas nicht tun. Nehmen Sie einfach Ihre Startlinie auf HotSpot, fügen Sie sie in eine spezielle GUI ein oder fügen Sie ein kleines Stück zu pom.xml hinzu, und nach einer Weile (da es sich immer noch um eine AOT-Zusammenstellung handelt) erhalten Sie eine Exe-Datei. welches ausgeführt werden kann.
Oleg: Muss ich lernen, mit GC zu arbeiten?
Nikita: Ja, wir haben unseren eigenen GC, wir müssen ihn anders einstellen, nicht wie bei HotSpot. Wir haben sehr wenige öffentliche Stifte.
Oleg: Gibt es einen Stift "gut machen" oder "nicht gut"?
Ivan: Da ist so ein Stift. Es gibt einen Stift "Set Xmx", es gibt einen Stift "Set die Anzahl der Arbeiter" ... Viele Stifte, aber warum müssen Sie über sie Bescheid wissen? Wenn Ihnen etwas Unerwartetes passiert - schreiben Sie.
Natürlich müssen wir viele Dinge für GC konfigurieren. Wir können die jüngere Generation einstellen, wir können die Häufigkeit der Ankunft von GC einstellen. All dies ist abgestimmt, aber dies sind keine allgemein akzeptierten Optionen. Wir verstehen, dass die Leute -Xmx kennen und darauf hinweisen, also analysieren wir es. Es gibt einige allgemein akzeptierte Optionen, die mit JET funktionieren, aber im Allgemeinen ist alles anders.
Nikita: Wir haben auch eine öffentliche Option, mit der Sie festlegen können, wie viel Zeit der GC für Ihre Anwendung aufwenden darf.
Oleg: Prozentsatz?
Nikita: In Zehntel Prozent. Wir haben festgestellt, dass das Interesse zu groß und unhöflich ist.
Ivan: Wenn Sie Interesse an GC haben, stimmt etwas nicht mit Ihnen.
Oleg: Und hier sind all diese Leute aus Unternehmen, die alles tun, was sie während der Arbeitszeit tun - sie öffnen einen Ausdruck der Arbeit von GC mit dem Zeitplan und meditieren. Kannst du meditieren?
Nikita: Wir haben spezielle Leute im Unternehmen, die meditieren.
Ivan: Wir haben unser eigenes Protokollformat, daher ist es unwahrscheinlich, dass die Leute etwas davon verstehen. Obwohl du es nie weißt? Wenn sie ihn lange ansehen, können sie es vielleicht verstehen. Dort steht alles geschrieben. Aber höchstwahrscheinlich ist es besser, uns zu schicken, und wir werden meditieren.
Oleg: Aber natürlich wirst du es für das Geld tun, aber du kannst selbst nach einem Werbegeschenk suchen.
Nikita: Wenn Sie unser Kunde sind, dann haben Sie Unterstützung, und wir tun dies natürlich als Teil der Unterstützung.
Ivan: Aber wenn Sie ein offensichtliches Problem haben, können wir sogar ohne Unterstützung sagen.
Oleg: Wenn das eine Art Fehler ist?
Nikita: Wenn ein Fehler, dann akzeptieren wir natürlich von allen und immer. Dies ist nicht so, "bis Sie kaufen, werden wir den Fehler nicht beheben." Wenn ein Fehler vorliegt, beheben wir ihn. Im Allgemeinen lieben Benutzer unsere Unterstützung. Normalerweise sagen sie, dass es von sehr hoher Qualität ist und dass sie so etwas nirgendwo gesehen haben. Vielleicht ist die Tatsache, dass wir uns selbst unterstützen, abwechselnd drehen.
Oleg: Wer sind sie selbst?
Nikita: Entwickler, JVM-Ingenieure.
Oleg: Wie oft?
Nikita: Die Frequenz ist unterschiedlich. Normalerweise sitzen wir zwei Wochen abwechselnd. Wenn Sie jedoch verpflichtet sind, in einer bestimmten Anzahl von Tagen ein Megaphic zu erstellen, erhalten Sie in diesem Moment Immunität von der Unterstützung, damit Sie sich auf diese Aufgabe konzentrieren können.
Ivan: Theoretisch sollte jeder dies nacheinander tun. Aber manchmal nimmt jemand heldenhaft die zweite Dosis und unterstützt sie für einen Monat oder länger und nicht für zwei Wochen. Persönlich unterstütze ich gerne, aber wenn Sie dies zu lange tun, vergessen Sie ein wenig, was Sie im Leben tun, weil Sie nur anfangen, Briefe zu beantworten. Aber Sie möchten immer noch die JVM Wurst. Daher müssen Sie nach einiger Zeit zurückkehren.
Oleg: Und Sie haben eine Hierarchie, wie viele Managementebenen? 20 oder mehr?
Nikita: Was bist du, wir sind nur 10 Leute in einem Team.
Ivan: 15 mit den Schülern.
Oleg: Ich meine, dass die Behörden daran beteiligt sind oder nur suchen?
Nikita: Über die Chefs. Natürlich gibt es eine Hauptperson, und es gibt viele lokale Führer.
Oleg: Hat jede Person ihren eigenen Bereich?
Nikita: Eine Person, die eine große Aufgabe übernimmt und sie verwaltet. Es dreht sich auch. Sie können eine große Aufgabe übernehmen und einmal führen, und beim nächsten Mal werden sie Sie führen.
Ivan: Im Allgemeinen haben wir keine große Hierarchie. Wir haben eine Ebene von Chefs. Und von oben schauen - absolut nicht. Manchmal übernehmen unsere Chefs heldenhaft Unterstützung, wenn eine Veröffentlichung in der Nähe ist.
Nikita: Die Chefs sind eine Person, sein Name ist Vitaly Mikheev.
Oleg: Kannst du ihn irgendwo sehen? Auf Konferenzen oder woanders?
Nikita: Im Allgemeinen begannen meine Reden auf Konferenzen mit der Tatsache, dass der Java-Tag in St. Petersburg in Nowosibirsk zu uns kam. Er wurde von Belokrylov von Oracle organisiert, der jetzt bei Bellsoft ist. Er fragte, ob wir sprechen möchten, und dann traten wir zusammen mit Vitaly auf. Dann schlug ich vor, dass er weiterhin zusammen auftreten sollte, aber er entschied, dass er es nicht mehr wollte.
Oleg: Und was für ein Bericht?
Nikita: "Die Geschichte einer JVM in Bildern . "
Ivan: Ich erinnere mich an diesen Bericht, dann war ich entweder Praktikant oder ich habe einfach aufgehört, einer zu sein. Und ich denke immer noch, dass dies einer der besten Berichte ist, die ich gesehen habe.
Nikita: Vielleicht war es der „Premiere-Effekt“, wenn Sie zum ersten Mal in Ihrem Leben auftreten und mit Energie gut drücken.
Oleg: Worüber hast du gesprochen?
Nikita: Sie haben 20 Minuten lang von Anfang bis Ende über JET gesprochen.
Oleg: Für zwei nur 20 Minuten? Bei mehreren Personen erhöht sich normalerweise nur die Zeit für einen Bericht.
Nikita: Wir haben sehr lebhaft und lebhaft über alle wichtigen Themen gesprochen.
Oleg: Wanja, hat sich das auf Ihre Entscheidung ausgewirkt, was als nächstes zu tun ist? Arbeiten Sie für das Unternehmen?
Ivan: Es könnte sein!
Oleg: Es ist nur so, dass die Leute normalerweise fragen, warum sie an Konferenzen oder Präsentationen teilnehmen, warum sie sich etwas anhören, wenn Sie es googeln können.
Nikita: Natürlich ist die Teilnahme an einer Konferenz meiner Meinung nach sehr nützlich. Wenn Sie einen direkten Kontakt haben und direkt teilnehmen, ist dies auf YouTube überhaupt nicht zu sehen. Es ist wichtig, dass Sie direkt und nicht virtuell teilnehmen. Sie stehen in Kontakt mit der Quelle. Der Unterschied ist ungefähr der gleiche wie beim Besuch eines Live-Konzerts oder beim Anhören auf einer Aufnahme. Wahrscheinlich sogar groß, denn wie viel kannst du nach dem Konzert mit deinem Lieblingskünstler sprechen? Aber auf der Konferenz können Sie den Sprecher finden, den Sie brauchen, und ihn nach allem fragen, was Sie brauchen - es gibt keine Probleme.
Ivan: Übrigens, was die Entscheidung betrifft, „im Unternehmen zu bleiben“, ist dies eine andere Geschichte. Wir haben ein ziemlich einzigartiges Rekrutierungssystem für Mitarbeiter / Praktikanten. Wir nehmen Praktikanten für 2-3 Kurse, normalerweise von der Fakultät oder von der Physikabteilung. Die Auszubildenden sind sehr tief in das Thema vertieft. Die Kuratoren helfen ihnen dabei, verschiedene VM-Mechanismen, Implementierungsdetails usw. zu verstehen. - Es kostet viel.
Nach einiger Zeit geben sie Kampfmissionen ab und schreiben echten Code in der Produktion. Sie nehmen Änderungen an der JVM vor, führen Überprüfungen, Tests und Benchmarks durch - stellen Sie sicher, dass sie nicht durchhängen. Sie verpflichten sich zum ersten Mal. Danach konzentrieren Sie sich auf Ihr Diplom. Normalerweise ist ein Diplom auch ein cooler Teil der experimentellen JVM-Forschung. Dies wird normalerweise von Studenten durchgeführt. Dann können Sie es produzieren - oder vielleicht auch nicht. Ich habe so etwas noch nie gesehen, so dass so viel Zeit für Praktikanten aufgewendet wird. Und ich persönlich schätze es sehr, weil ich mich daran erinnere, wie viel Zeit ich für mich aufgewendet habe. Die Ausgabe ist ein JVM-Ingenieur. Wo sonst geht es in einer solchen Fabrik um die Produktion von JVM-Ingenieuren?
Oleg: Und Sie haben keine Angst vor Informationslecks von Praktikanten, dann werden sie dies alles in einem Diplom offen beschreiben?
Nikita: Das ist kein Problem, weil wir Angst vor einem Leck im Ausland haben und vor allem niemand Russisch lesen wird - das ist so ein Schutz, Verschleierung :-)
Ivan: Ich hatte einen Studenten, der dieses Jahr verteidigte, ich war der Anführer, und es gab ein solches Problem, dass nicht jeder in einem Diplom schreiben wollte. Wir haben etwas aus einem völlig geschlossenen Thema enthüllt, und zum Beispiel hat uns ein Rezensent gefragt, warum wir nicht über bestimmte Dinge gesprochen haben. Ich habe ihm gesagt, dass du nicht darüber reden kannst, es ist sehr geheim, wir können nicht. Es ist, ich werde es dir ins Ohr sagen, aber es wird nirgendwo anders hingehen. Wir haben ein wenig Angst davor, aber im Allgemeinen finden Sie in Diplomen viele interessante Dinge.
Oleg: Und wie sucht man nach Diplomen, an denen Excelsior beteiligt ist?
Nikita: Komm ins Dekanat und bitte um ein solches Diplom.
Ivan: Wir haben eine Liste erfolgreich verteidigter Diplome auf unserer Seite, aber nur Namen ohne Links. Und wir haben keine erfolglos verteidigt.
Oleg: Sie sterben entweder oder verteidigen sich.
Ivan: Das ist es! Wir haben eine durchschnittliche Punktzahl von 5,0 Absolventen, es gibt diejenigen, die einfach kein Diplom machen.
Oleg: In dieser Schulung, der Fabrik der JVM-Ingenieure, sagen Sie uns, wie es ist, ein Jedi zu werden. Wenn sie dir ein Lichtschwert geben, wann kannst du anfangen, sie zu winken?
Nikita: Ziemlich schnell. Jetzt werden die Jugendlichen schmerzlich schnell zu Jedi, ich bin stolz auf sie.
Ivan: Nikita war übrigens mein erster Kurator, als ich Praktikant war. Zum Praktikum: Zuerst gehen Sie eine Auswahl durch: Sie lösen Probleme, kommen zu einem oder mehreren Interviews. Wenn alles in Ordnung ist, werden Sie Auszubildender. Zuerst lesen Sie wissenschaftliche Artikel zu Themen, die höchstwahrscheinlich mit Ihrem zukünftigen Diplom zusammenhängen, oder nur zu JVM-Themen auf Englisch, um den Kontext zu ermitteln. Sie lesen, schreiben einen Aufsatz darüber, erklären, was dort passiert. Sie sind sehr hart gegen ihn. Einige Gelehrte würden ein solches Korrekturlesen und eine solche Aufsatzvorbereitung beneiden. Es stellt sich heraus, vollwertige Artikel in russischer Sprache. Danach ist es Zeit für Sie, den Code zu schreiben, und Sie werden langsam in das Wesentliche der Sache eingeführt - wie alles funktioniert.
Nikita: Und hier endet die Wissenschaft.
Ivan: Nicht unbedingt!
Nikita: Es ist eine Schande, dass wir zu Beginn der Null Artikel veröffentlicht haben, die wir in ACM-Magazinen veröffentlicht haben.
Ivan: Nun, wir machen es jetzt, was ist das Problem?
Nikita: Was war unser letzter Artikel im ACM-Magazin?
Ivan: Also in ACM haben wir es einfach nicht versucht! Jetzt bloggen wir - es ist dasselbe, nur die Leute lesen es. Dies ist eine ähnliche Aktivität.
Zurück zum Jedi-Thema: Danach machen Sie das erste Mal etwas in der Produktion unter strenger Kontrolle. Es wird eine kleine Aufgabe benötigt, die nicht mit Ihrem zukünftigen Diplom zusammenhängt.
Oleg: Zum Beispiel einen Kommentar schreiben.
Ivan: Nein. Wahre Funktionalität. Der Student muss seinen ersten wirklichen Beitrag leisten, damit er im Produkt bleibt. , - , . , -, — . , . , JVM-.
: ? ? - , , - ? ?
: , . - — - , , , , , , JVM. , , , . , : « !». .
: JET?
: , JVM .
: - , JET — JET. , - , : baseline-. , . , , JET .
: ?
: , . , .
: - , baseline .
: , baseline JIT. , JIT , . , baseline. . - , baseline, .
: - UI-? .
: . . Windows.
: , . , Mac.
: Android ?
: . , Android Linux-, Linux . Linux Android . - . .
: ?
: ? Nein.
: Android Native SDK. DLL .
: , - , . SO- - , , Linux, , , . Java Android, , SO-, Java Dalvik . 90 , , -.
: iOS ?
: . Android, iOS. , , .
: , 15 .
: iOS . , .
: , .
: ?
: , — .
: . ?
: — JVM, JVM — , , , , , — , . , . . GC - , , . , , , .
: , , , . , , . GDB .
: , . , .. , .. managed- Java/Scala, ( ) IDEA, . — GDB .
: , , unit- , !
: . . , , , . JVM. -, . , : , - « - ( ) . ».
, , — , JVM.
: ?
: .
: . . Spring Boot , JET , .
: , - . , , , — . , JIT, . , .
: JIT — , ?
: , .
: , - , .
: , ? , -, , .
: , , - -. - , , . , . , - . issue-, , . , , .
, . , — , -. , . check-in , 1.5-2 .
: Visual Source Safe, check-in. VSS , check-in . VSS, check-in .
: , JET, JVM , . 1.5-2 . JET, , . - , , , — . ? . .
: JET Scala?
: Scala.
JET Scala, JET-. JET- . , . , Scala-, scalac, …
: check-in Java- , , , .
: - , C++ ?
: , . , , .
: JVM- — , - , . — . , , , — , . , . « ». . , , , :-) — . , GC, - - . , - , , . , - . .
: , ?
: . , . , . QA-, — , . , .
: ?
: , . , , . , . C GC . , , - . , GC - — . - . ? ?
: , .
: , -, . . , — . . - .
: , , , .
: , - ?
: - , .
: JIT?
: JIT . assert, , -, , . .
: , . JCK . - JCK, , . , . UI-, GUI-, JET. - . , GitHub JET-. JET- . QA- , .
: , ? , , ?
: QA Lead — -. QA, . , . , , . , .
: , QA ? , QA-, , — , , . , , - -.
: , . , , , - . , QA Lead , . JVM-, , .
: ? - , QA- , — ?
: JCK, Oracle. Oracle , . - . JCK, - , , , .
: , JCK?
: Oracle. , JVM, - , Oracle.
: . , Open JDK, JCK.
: - , , - , — , . , , - Oracle. , , Oracle .
: ?
: . , - , «value add». JCK, Java, . JCK , — .
: ! , OpenJDK, ?
: . , 70 . , JCK, , , . , , JET , HotSpot . .
: ? .
: Oracle JVM. . « JVM» Joker.
: ?
: , . JVM. : JVM- , , , . , .
: , JCK ?
: , . mailing list, (Alex Buckley), , Java/JVM-, JVM Specification 12.
: JCK .
: JCK, Sun . , — .
: — , ?
: , . . , , CORBA. , - , . 6 , CORBA . , , HotSpot, , , .
: , — ?
: . CORBA , . Swing . JCK Swing, , . .
: « JCK».
: , , JCK . .
: ?
: , , , , , .
: , .
: - , . , . .
: , ?
: , .
: . , . : , . , JCK, Java.
, . - .
: — . , , — . , - . , . , .
: - , ? ?
: — . , - - , - - . Java - ! , GC. — — , .
: , , . (, JVM ). , ? Aber nichts. , - - , . JVM , . , .
Java . , , — . Loom Metropolis, Java. - JVM, , , , , . Loom , , . . , — .
. , Java — , 5-6 Java- JPoint . , Java- (Simon Ritter, Rafael Winterhalter). , Call for Papers 31 . . , YouTube. JPoint!