Nous avons récemment écrit sur les astuces d'Alibaba pour rendre la vie avec OpenJDK plus acceptable. Il y a eu des commentaires comme "il s'avère que pendant que nous souffrons de Java ordinaire, les Chinois ont déjà fait leur propre spécial." Alibaba, bien sûr, est impressionnant - mais la Russie a aussi ses propres projets fondamentaux, où ils font également du «Java spécial».
À Novossibirsk, depuis 18 ans, ils créent leur propre machine virtuelle Java , écrite de manière totalement indépendante et en demande bien au-delà des frontières de la Russie. Ce n'est pas seulement une sorte de fourchette HotSpot qui fait la même chose, mais un peu mieux. Excelsior JET est une suite de solutions qui vous permet de faire des choses complètement différentes en termes de compilation AOT. "Pff, AOT est dans GraalVM", vous pouvez dire. Mais GraalVM est encore une chose très exploratoire, et JET est une solution éprouvée pour une utilisation en production.
Ceci est une interview avec l'un des développeurs d' Excelsior JET. J'espère que cela sera particulièrement intéressant pour tous ceux qui veulent découvrir de nouvelles choses qui peuvent être faites avec Java. Ou des personnes qui s'intéressent à la vie des ingénieurs JVM et qui souhaitent y participer.
À l'automne, je me suis envolé pour l'une des conférences Java de Novossibirsk, nous nous sommes assis avec Ivan Uglyansky dbg_nsk et Nikita Lipsky pjBooms (l'un des développeurs de JET) et avons enregistré cette interview. Ivan est engagé dans le runtime JET: GC, chargement de classe, support multithreading, profilage, plugin pour GDB. Nikita - l'un des initiateurs du projet JET, a participé à la recherche et au développement de presque tous les composants du produit du noyau aux propriétés du produit - OSGi au niveau de la JVM, Java Runtime Slim Down (les modules Java dans JET étaient déjà en 2007), deux vérificateurs de bytecode, support Botte de printemps et ainsi de suite.
Oleg Chirukhin: Pouvez-vous dire pour les ignorants votre produit?
Nikita Lipsky: Il est surprenant, bien sûr, que nous soyons sur le marché depuis 18 ans, et nous ne savons pas grand-chose. Nous faisons une JVM inhabituelle. Insolite en pariant sur la compilation AOT, c.-à-d. nous essayons de compiler le bytecode Java en code machine à l'avance.
Initialement, l'idée du projet était de rendre Java rapide. La productivité est ce avec quoi nous sommes allés sur le marché. Et pendant que nous marchions, Java était toujours interprété, et la compilation statique dans le code machine promettait d'améliorer les performances Java même pas parfois, mais par ordre de grandeur. Mais même en présence de JIT, si vous compilez tout à l'avance, vous ne dépensez pas de ressources au moment de l'exécution pour la compilation, et ainsi, vous pouvez dépenser plus de temps et de mémoire et finalement obtenir un code plus optimisé.
En plus des performances, un effet secondaire de la compilation de bytecode statique est la protection des applications Java contre la décompilation. Parce qu'après la compilation, il n'y a plus de bytecode, seul le code machine reste. Il est beaucoup plus difficile de décompiler en code source que le bytecode Java. En fait, impossible. Autrement dit, il peut être démonté, mais vous ne donnerez pas naissance à des codes source. Mais le code source Java peut être généré facilement à partir du bytecode jusqu'aux noms de variables, il existe de nombreux outils pour cela.
De plus, il était une fois supposé que Java était installé sur tous les ordinateurs, vous distribuiez vos applications Java sous forme de bytecode, et elles exécutaient la même partout. Mais en réalité, tout n'était pas si bon, car l'un a un Java, l'autre en a un autre. De ce fait, si vous distribuiez le programme sous forme de bytecode, toutes sortes de surprises pouvaient survenir, à commencer par le fait que l'utilisateur ne pouvait tout simplement pas démarrer votre programme, se terminant par un comportement étrange que vous ne pouviez pas montrer en vous-même. Notre produit a toujours eu l'avantage de distribuer votre application Java simplement en tant qu'application native. Vous ne dépendez pas du runtime que l'utilisateur vaut (ou ne vaut pas).
Ivan Uglyansky: Généralement, vous n'avez pas besoin d'exiger Java pour être installé.
Oleg: Il reste une dépendance vis-à-vis du système d'exploitation, non?
Nikita: D' accord. Beaucoup critiquent que si vous compilez en code natif, votre slogan «Écrire une fois - exécuter n'importe où» cesse de fonctionner. Mais ce n'est pas le cas. J'en parle périodiquement dans mes rapports que «écrire une fois» sonne comme «écrire une fois» et non «construire une fois». Autrement dit, vous pouvez créer votre application Java sur chaque plate-forme, et cela fonctionnera partout.
Oleg: Direct partout, partout?
Nikita: Partout où pris en charge. Nous avons une solution compatible Java. Si vous écrivez en Java, cela fonctionnera là où Java fonctionne. Et si vous utilisez le compilé par nous, alors là où nous le supportons - Windows, Linux, Mac, x86, amd64, ARM32. Mais là où nous ne le prenons pas en charge, vous pouvez toujours utiliser Java standard pour vos applications, c'est-à-dire que la portabilité de vos applications Java en ce sens ne souffre pas.
Oleg: Existe-t-il de telles conceptions qui sont implémentées différemment sur différentes plates-formes? Morceaux de la plate-forme qui ne sont pas entièrement implémentés, certaines bibliothèques standard.
Ivan: Cela arrive, mais ce n'est pas spécifique au JET. Vous pouvez regarder, par exemple, l'implémentation AsynchronousFileChannel dans le JDK lui-même, elle est complètement différente sur différents Windows et sur Posix, ce qui est logique. Certaines choses ne sont implémentées que sur certaines plates-formes, la prise en charge SCTP (voir sun.nio.ch.sctp.SctpChannelImpl sur Windows) et SDP (voir sun.net.sdp.SdpSupport). Il n'y a pas de contradiction particulière à cela, mais il s'avère vraiment que «Écrire une fois, exécuter n'importe où» n'est pas tout à fait vrai.
En parlant spécifiquement de la mise en œuvre de la JVM, puis sur différents systèmes d'exploitation, la différence peut bien sûr être énorme. Quel est le fait que sur OS X dans le thread principal, vous devez exécuter la boucle d'événements Cocoa, donc le lancement est différent du reste.
Nikita: Néanmoins, de l'extérieur, pour l'utilisateur, tout cela ressemble et fonctionne presque de la même manière.
Oleg: Et la performance? Est-ce la même chose sur toutes les plateformes?
Nikita: Il y a une différence. Par exemple, un système de fichiers Linux fonctionne mieux et plus rapidement qu'un système de fichiers Windows.
Oleg: Et le portage entre processeurs?
Nikita: C'est une activité amusante! Toute l'équipe commence soudainement à mettre en communication. Le divertissement dure généralement de six mois à un an.
Oleg: Il arrive qu'un morceau de code sur une autre plateforme commence à ralentir davantage?
Ivan: Cela peut être dû au fait que nous n'avons tout simplement pas eu le temps de faire ou d'adapter une sorte d'optimisation. Cela a bien fonctionné sur x86, puis nous sommes passés à AMD64 et n'avons tout simplement pas réussi à l'adapter. Pour cette raison, cela peut être plus lent.
Un autre exemple de performances. ARM a un modèle de mémoire faible, vous devez y mettre beaucoup plus de barrières pour que tout fonctionne correctement. Nous avions AMD64, certains endroits fonctionnaient, pensez, gratuitement alors, car là le modèle de mémoire est différent. Vous devez mettre plus de barrières sur ARM, et ce n'est pas gratuit.
Oleg: Parlons maintenant du sujet brûlant - "Java sur les appareils embarqués".
Disons que je fais un avion qui vole avec contrôle sur un Raspberry Pi. Quels sont les problèmes typiques d'une personne lorsqu'elle fait cela? Et comment la compilation JET et généralement AOT peut-elle aider dans ce domaine?
Nikita: L' avion sur le Raspberry Pi est, bien sûr, un sujet intéressant. Nous avons créé ARM32, et maintenant JET est sur le Raspberry Pi. Nous avons un nombre illimité de clients pour l'embedded, mais il n'y en a pas tellement pour parler de leurs problèmes "typiques". Bien qu'ils aient des problèmes avec Java, ce n'est pas difficile à deviner.
Ivan: Quels sont les problèmes avec Java sur le Raspberry Pi? Il y a un problème avec la consommation de mémoire. Si vous en avez trop besoin, l'application et la JVM sont difficiles à vivre sur le pauvre Raspberry Pi. De plus, il est important d'avoir un démarrage rapide sur les appareils embarqués pour que l'application n'y accélère pas trop longtemps. AOT résout bien ces deux problèmes, nous travaillons donc à améliorer le support intégré. Plus précisément, en ce qui concerne le Raspberry Pi, il convient de mentionner Bellsoft , qui est désormais activement engagé dans ce domaine avec HotSpot. Le Java normal y est pleinement présent.
Nikita: De plus, il y a peu de ressources sur les systèmes embarqués; le compilateur JIT n'a nulle part où se déployer. Par conséquent, la compilation AOT accélère à elle seule les performances.
Encore une fois, les appareils intégrés sont sans connexion au réseau, sur une batterie. Pourquoi y a-t-il une batterie pour le compilateur JIT si vous pouvez tout assembler à l'avance?
Oleg: Quelles sont vos fonctionnalités? Je comprends que JET est un très grand système complexe avec un tas de tout. Vous avez une compilation AOT, c'est-à-dire que vous pouvez compiler un exécutable. Quoi d'autre? Quels sont les éléments intéressants qui méritent d'être évoqués?
Ivan: Nous avons un certain nombre de fonctionnalités liées aux performances.
Récemment, j'ai parlé de PGO, notre fonctionnalité relativement nouvelle. Nous avons un profileur intégré directement dans la machine virtuelle Java, ainsi qu'un ensemble d'optimisations en fonction du profil qu'il recueille. Après une recompilation basée sur le profil, nous obtenons souvent une sérieuse amélioration des performances. Le fait est que les informations sur les performances sont ajoutées à nos puissantes analyses statiques et optimisations. C'est une approche légèrement hybride pour tirer le meilleur parti de la compilation JIT et AOT.
Nous avons deux fonctionnalités merveilleuses pour une accélération de lancement encore plus rapide. Le premier est lorsque vous regardez l'ordre dans lequel les pages mémoire sont initialement percées, il vous suffit de le surveiller et de lier l'exécutable en conséquence.
Nikita: Deuxièmement - lorsque vous lancez l'exécutable, vous comprenez quels éléments de la mémoire sont extraits, puis au lieu de les extraire dans n'importe quel ordre, vous extrayez immédiatement l'élément souhaité. Accélère également considérablement le lancement.
Ivan: Ce sont des fonctionnalités d'épicerie individuelles.
Nikita: Le premier s'appelle Startup Optimizer et le second est Startup Accelerator. Les fonctionnalités fonctionnent différemment. Pour utiliser la première, vous devez exécuter l'application avant la compilation, elle se souviendra dans quel ordre le code a été exécuté. Ensuite, dans le bon ordre, ce code sera lié. Et le second lance votre application après la compilation, alors nous savons déjà ce qui s'est passé où et où, et après cela nous avons tout percé dans le bon ordre au lancement.
En plus des fonctionnalités liées aux performances, il existe un certain nombre de fonctionnalités du produit qui rendent JET plus pratique à utiliser.
Par exemple, nous pouvons emballer, disons, des distributions Windows. Une fois - et j'ai obtenu un programme d'installation de Windows. Vous pouvez distribuer des applications Java en tant que vraies applications natives. Il y a bien plus. Par exemple, il existe un tel problème standard avec les compilateurs AOT et Java lorsqu'une application utilise ses propres chargeurs de classe. Si vous avez votre propre chargeur de classe, il n'est pas clair quelles classes nous allons AOT compiler? Parce que là la logique de résolution entre les classes peut être n'importe quoi. Par conséquent, pas un seul compilateur Java AOT, à l'exception du nôtre, ne fonctionne avec des chargeurs de classe non standard. Nous avons un support spécial dans AOT pour certaines classes d'applications, où nous savons comment leurs chargeurs personnalisés fonctionnent, comment les liens entre les classes sont résolus. Par exemple, nous prenons en charge Eclipse RCP et certains clients écrivent des applications de bureau sur Eclipse RCP et les compilent avec nous. Il y a un support pour Tomcat, des chargeurs personnalisés y sont également utilisés. Vous pouvez compiler des applications Tomcat avec nous. Nous avons également récemment sorti une version Spring Boot JET prête à l'emploi.
Oleg: Quel serveur y a-t-il "ci-dessous"?
Nikita: Tout ce que tu veux. Quels supports Spring Boot fonctionneront avec cela. Tomcat, Undertow, Jetty, Webflux.
Ivan: Ici, il est nécessaire de mentionner que pour Jetty, nous n'avons pas le support de ses chargeurs de classe personnalisés.
Nikita: Jetty, en tant que serveur Web autonome, dispose d'un chargeur de classe personnalisé. Mais il existe une chose telle que Jetty Embedded, qui peut fonctionner sans chargeurs personnalisés. Jetty Embedded fonctionne silencieusement sur Excelsior JET. À l'intérieur de Spring Boot, Jetty fonctionnera dans la prochaine version, comme tous les autres serveurs pris en charge par Spring Boot.
Oleg: En fait, l'interface utilisateur avec JET est javac et Java, ou autre chose?
Ivan: Non. Pour l'utilisateur, nous avons plusieurs options pour utiliser JET. Tout d'abord, il s'agit d'une interface graphique dans laquelle l'utilisateur perce toutes les fonctionnalités, après quoi il appuie sur un bouton et son application se compile. Quand il veut faire un installateur pour que l'utilisateur puisse installer l'application, il pousse à nouveau les boutons. Mais cette approche est un peu dépassée (les interfaces graphiques ont été développées en 2003), nous avons donc maintenant Nikita développant et développant des plugins pour Maven et Gradle, qui sont beaucoup plus pratiques et familiers pour les utilisateurs modernes.
Nikita: Remplacez sept lignes dans pom.xml ou build.gradle, par exemple mvn jet:build , et vous avez un bâton de saucisse sur la sortie.
Oleg: Et maintenant tout le monde aime beaucoup Docker et Kubernetes, pouvez-vous construire pour eux?
Nikita: Docker est le sujet suivant. Nous avons un tel paramètre - le conditionnement dans les plugins Maven / Gradle. Je peux ajouter des applications de packaging pour Docker.
Ivan: C'est encore du travail en cours. Mais dans l'ensemble, nous avons essayé les applications compilées JET pour fonctionner sur Docker.
Nikita: Ça marche. Sans Java. Naked Linux, collez-y l'application compilée JET, et ça démarre.
Oleg: Et avec l'emballage du docker, quelle sera la sortie? Pousser un conteneur ou un exécutable avec vos mains dans le fichier Docker?
Nikita: Maintenant, vous venez d'écrire un fichier Docker spécifique à JET - ce sont trois lignes. De plus, tout fonctionne grâce aux outils Docker classiques.
Je joue avec des microservices en ce moment. Je les compile avec JET, les exécute, ils se découvrent, communiquent. La JVM n'avait rien à faire pour cela.
Oleg: Maintenant, toutes sortes de fournisseurs de cloud ont lancé des choses comme Amazon Lambda, Google Cloud Functions, puis-je l'utiliser là-bas?
Nikita: Je pense que nous devons aller voir les fournisseurs de toutes ces choses et dire que si vous nous utilisez, tous vos lambdas fonctionneront plus rapidement. Mais ce n'est encore qu'une idée.
Oleg: Donc, ils fonctionneront vraiment plus vite!
Nikita: Oui, très probablement, plus de travail doit être fait dans cette direction.
Oleg: Je vois un problème dans le temps de compilation lambda. Quel est votre temps de compilation?
Ivan: Cela existe, et c'est un problème auquel les utilisateurs de machines virtuelles Java ordinaires avec JIT ne pensent pas. Habituellement, après tout, comment - j'ai lancé l'application, cela fonctionne (bien que lentement au début à cause de la compilation). Et voici une étape distincte pour la compilation AOT de l'ensemble de l'application. Cela peut être sensible, nous travaillons donc à accélérer cette phase. Par exemple, nous avons une recompilation incrémentielle lorsque seules les parties modifiées de l'application sont recompilées. Nous appelons cela une recompilation intelligente. Nous venons de le faire dans la dernière période vierge avec Nikita, nous étions jumelés.
Nikita: Il y a certains problèmes avec Java et avec la recompilation intelligente, par exemple, les dépendances circulaires dans les applications Java - elles sont partout.
Ivan: Il y a là beaucoup de problèmes plutôt non évidents, jusqu'à ce que vous réfléchissiez à cette tâche. Si vous disposez d'un compilateur AOT statique qui effectue diverses optimisations globales, il n'est pas si facile de calculer exactement ce qui doit être recompilé. Vous devez vous souvenir de toutes ces optimisations. Et les optimisations peuvent être non triviales. Par exemple, vous pourriez faire toutes sortes de dévirtualisations complexes, en ligne quelque chose que le diable sait où. Si vous avez changé un classique ou un JAR, cela ne signifie pas que seul il doit être recompilé et c'est tout. Non, c'est beaucoup plus déroutant. Vous devez calculer et mémoriser toutes les optimisations effectuées par le compilateur.
Nikita: En fait, faire la même chose que JIT quand il prend une décision concernant la désoptimisation, mais uniquement dans le compilateur AOT. Seule la solution ne sera pas la désoptimisation, mais la recompilation.
Oleg: À propos de la vitesse de compilation intelligente. Si je prends "Hello, World", le compile, puis change les deux lettres du mot "Hello" ...
Nikita: Il se compile rapidement.
Oleg: Je veux dire, pas une minute?
Nikita: Secondes.
Ivan: Mais cela dépend toujours si nous incluons des classes de plate-forme dans l'exécutable.
Oleg: Et qu'est-ce qui est possible sans ça?
Nikita: Oui, par défaut, notre plateforme est sciée en plusieurs DLL. Nous avons implémenté Jigsaw au tout début :-) Autrement dit, nous avons scié des classes Java SE sur des composants il y a très longtemps, il y a environ 90 ans.
Ivan: Le fait est que nos classes d'exécution plus plate-forme - elles sont toutes précompilées par nous, et oui - sont divisées en DLL. Lorsque vous exécutez l'application compilée par JET, le runtime et la plate-forme entière sont présentés sous la forme de ces DLL. Autrement dit, cela ressemble à ceci: vous prenez "Bonjour, monde", compilez, vous compilez vraiment une classe. Cela se produit en quelques secondes.
Nikita: En 4 secondes, si dans le monde; en quelques secondes, sinon dans le monde. «Global», c'est quand vous liez: toutes les classes de plate-forme compilées en code natif en un seul grand exécutable.
Oleg: Puis-je recharger à chaud?
Nikita: Non.
Oleg: Non? Tristesse. Mais il serait possible de générer une DLL, de la lier à nouveau puis ...
Nikita: Puisque nous avons JIT (en passant, oui, nous avons JIT aussi!), Alors bien sûr, vous pouvez charger, décharger, recharger des morceaux de code. Par exemple, tout le code qui fonctionne via notre JIT est dans le même OSGI - vous pouvez le recharger si vous le souhaitez. Mais voici le rechargement à chaud que HotSpot a, lorsque vous vous asseyez dans le débogueur et changez le code à la volée, nous ne le faisons pas. Cela ne peut se faire sans perte de performances.
Oleg: Au stade du développement, les performances ne sont pas si importantes.
Nikita: Au stade du développement, vous utilisez HotSpot et vous n'avez besoin de rien d'autre. Nous sommes une solution compatible Java. Si vous utilisez HotSpot et utilisez le rechargement à chaud dans le débogage, tout va bien. Débogué, compilé JET, et tout fonctionne comme sur HotSpot. Ça devrait être comme ça. Habituellement comme ça. Sinon, vous écrivez au support, nous comprenons.
Oleg: Et le débogage dans JET? JVM TI? Combien tout est pris en charge?
Ivan: L'une des valeurs fondamentales de l'utilisation de JET est la sécurité. Le code personnalisé ne sera accessible à personne. Parce que tout est compilé en natif. Il y a quelques contradictions avec cela, prenons-nous en charge JVM TI? Si nous prenons en charge, cela signifie que tout développeur développé qui sait comment fonctionne la JVM TI pourra accéder rapidement à tout. Nous ne prenons pas en charge JVM TI pour le moment.
Nikita: Il s'agit d'un élément de spécification facultatif. Il peut être pris en charge par les implémenteurs de plate-forme, peut ne pas être pris en charge.
Ivan: Il y a plusieurs raisons. Il est facultatif et viole la sécurité, ce qui signifie que les utilisateurs ne nous diront pas «merci». Et elle est à l'intérieur est très spécifique à HotSpot. Il n'y a pas si longtemps, nos gars soutenaient la JVM TI en tant que projet expérimental, ils atteignaient une certaine étape, mais tout le temps ils étaient confrontés au fait qu'elle était très concentrée sur HotSpot. En principe, cela est possible, mais quelle tâche commerciale sera résolue?
Nikita: Après avoir gagné de l'argent sur HotSpot, mais vous n'avez pas gagné d'argent sur un jet - ce n'est pas votre problème. Tel est notre problème.
Oleg: J'ai compris. Avez-vous des fonctionnalités supplémentaires, qui
pas dans HotSpot, mais en avez-vous un et ils nécessitent un contrôle direct? Que je voudrais déboguer, les trier.
Nikita: Exactement une fonctionnalité. Nous avons une extension officielle de la plate-forme appelée Windows Services, c'est-à-dire que vous pouvez compiler des applications Java sous la forme de vrais services Windows qui seront surveillés via des outils Windows standard pour les services Windows, etc. Dans ce cas, vous devez récupérer notre propre JAR afin de compiler de telles applications.
Oleg: Ce n'est pas le plus gros problème.
Nikita: L'interface est très simple pour ces services. Et pour le débogage, vous utilisez les méthodes de démarrage de votre propre application non pas en tant que service Windows, mais via main. Une sorte de débogage spécifique au service, je ne sais pas si c'est nécessaire.
Oleg: Supposons qu'un nouveau développeur qui a précédemment travaillé pour HotSpot souhaite développer quelque chose à l'aide de JET, a-t-il besoin d'apprendre quelque chose, de comprendre quelque chose en général sur la vie ou sur JET?
Ivan: Il doit copier sept lignes dans pom.xml, si Maven est utilisé, puis lancer jet: build, et si JET est sur la machine, alors l'application Java sera compilée en un exécutable. L'idée est que c'est simple, vous ne faites rien de spécial, vous le prenez juste, obtenez un exécutable, et c'est tout.
Nikita: Soit vous connaissez la ligne de commande avec laquelle votre application est lancée, alors vous mettez cette ligne de commande dans notre interface graphique, elle le comprendra. Vous donnez la commande build, vous obtenez l'exécutable, c'est tout.
Ivan: C'est très simple, vous n'avez pas besoin d'inventer quelque chose de nouveau. Comment fonctionne le hotspot AOT, vous avez vous-même montré dans le rapport que vous devez obtenir une liste de toutes les méthodes dans un fichier, le balayer, le transformer - nous n'avons pas besoin de faire quelque chose comme ça. Prenez simplement votre ligne de lancement sur HotSpot, collez-la dans une interface graphique spéciale, ou ajoutez un petit morceau à pom.xml, et, cheers, après un certain temps (car c'est toujours une compilation AOT), vous obtenez un fichier exe, qui peut être exécuté.
Oleg: Dois-je apprendre à travailler avec GC?
Nikita: Oui, nous avons notre propre GC, nous devons le régler d'une manière différente, pas comme dans HotSpot. Nous avons très peu de stylos publics.
Oleg: Y a-t-il un stylo «bien faire» ou «ne pas faire»?
Ivan: Il y a un tel stylo. Il y a un stylo «set Xmx», il y a un stylo «set the number of workers» ... Beaucoup de stylos, mais pourquoi avez-vous besoin de les connaître? Si quelque chose d'inattendu vous arrive, écrivez.
Bien sûr, nous avons beaucoup de choses à configurer GC. Nous pouvons régler la jeune génération, nous pouvons la fréquence d'arrivée de GC. Tout cela est réglé, mais ce ne sont pas des options généralement acceptées. Nous comprenons que les gens connaissent -Xmx et le signalons, alors nous l'analysons. Il existe des options plus généralement acceptées qui fonctionnent avec JET, mais en général, tout est différent.
Nikita: Nous avons également une option publique qui vous permet de définir combien vous autorisez le GC à passer du temps sur votre application.
Oleg: Pourcentage?
Nikita: En dixièmes de pour cent. Nous avons réalisé que l'intérêt était trop, grossier.
Ivan: Si vous dépensez de l'intérêt pour GC, quelque chose ne va pas chez vous.
Oleg: Et voici toutes ces personnes d'entreprises qui font tout ce qu'elles font pendant les heures de travail - elles ouvrent une impression du travail du GC avec le calendrier et méditent. Pouvez-vous méditer?
Nikita: Nous avons des personnes spéciales au sein de l'entreprise qui méditent.
Ivan: Nous avons notre propre format de journal, il est donc peu probable que les gens en comprennent quelque chose. Mais tu ne sais jamais? S'ils le regardent longtemps, ils peuvent peut-être comprendre. Tout y est écrit. Mais, très probablement, il vaut mieux nous envoyer, et nous méditerons.
Oleg: Mais bien sûr, vous le ferez pour l'argent, mais vous pouvez chercher un cadeau vous-même.
Nikita: Si vous êtes notre client, alors vous avez du support, et nous le faisons, bien sûr, dans le cadre du support.
Ivan: Mais si vous avez un problème évident, nous pouvons même dire sans soutien.
Oleg: S'il s'agit d'une sorte de bug?
Nikita: Si un bug, alors, bien sûr, nous acceptons de tout le monde et toujours. Ce n'est pas le cas, "jusqu'à ce que vous achetiez, nous ne corrigerons pas le bogue". Si un bogue, nous le corrigeons. En général, les utilisateurs adorent notre support. Habituellement, ils disent que c'est de très haute qualité et qu'ils n'ont rien vu de semblable nulle part. Peut-être le fait est que nous sommes nous-mêmes en soutien, tour à tour.
Oleg: Qui sont-ils eux-mêmes?
Nikita: développeurs, ingénieurs JVM.
Oleg: À quelle fréquence?
Nikita: La fréquence est différente. Habituellement, nous nous asseyons à tour de rôle pendant deux semaines. Mais si vous êtes obligé de faire un mégapha dans un certain nombre de jours, à ce moment-là, vous recevrez une immunité de soutien afin que vous puissiez vous concentrer sur cette tâche.
Ivan: En théorie, tout le monde devrait le faire à son tour. Mais parfois, quelqu'un prend héroïquement la deuxième dose et prend en charge pendant un mois ou plus, et non pas deux semaines. Personnellement, j'aime soutenir, mais si vous faites cela trop longtemps, alors vous oubliez un peu ce que vous faites dans la vie, car vous ne commencez qu'à répondre aux lettres. Mais vous voulez toujours saucisse la JVM. Par conséquent, après un certain temps, vous devez revenir.
Oleg: Et vous avez une hiérarchie, combien de niveaux de gestion? 20 ou plus?
Nikita: Que faites-vous, nous ne sommes que 10 personnes dans une équipe.
Ivan: 15 avec les étudiants.
Oleg: Je veux dire que les autorités sont impliquées dans cela ou simplement en train de chercher?
Nikita: À propos des patrons. Bien sûr, il y a une personne principale et de nombreux dirigeants locaux.
Oleg: Chaque personne a-t-elle son propre espace?
Nikita: Une personne qui assume une grosse tâche et la gère. Il tourne aussi. Vous pouvez prendre une grande tâche et diriger une fois, et la prochaine fois, ils vous dirigeront.
Ivan: En général, nous n'avons pas de grande hiérarchie. Nous avons un niveau de boss. Et de regarder d'en haut - absolument pas. Parfois, nos patrons assument héroïquement le soutien si une version est proche.
Nikita: Les patrons sont une seule personne, son nom est Vitaly Mikheev.
Oleg: Pouvez-vous le voir quelque part? Lors de conférences ou ailleurs?
Nikita: En général, mes discours lors de conférences ont commencé avec le fait que la Journée de Java de Saint-Pétersbourg nous est venue à Novossibirsk, elle était organisée par Belokrylov d'Oracle, qui est maintenant à Bellsoft. Il a demandé si nous aimerions parler, puis nous avons joué avec Vitaly. Puis je lui ai suggéré de continuer à jouer ensemble, mais il a décidé qu'il ne voulait plus.
Oleg: Et quel genre de rapport?
Nikita: "L'histoire d'une machine virtuelle Java en images . "
Ivan: Je me souviens de ce rapport, alors j'étais soit stagiaire, soit j'ai cessé de l'être. Et je pense toujours que c'est l'un des meilleurs rapports que j'ai vus.
Nikita: C'était peut - être «l'effet de première» lorsque vous jouez pour la première fois de votre vie, vous appuyez bien avec énergie.
Oleg: De quoi parliez-vous?
Nikita: Ils ont parlé ensemble du JET du début à la fin pendant 20 minutes.
Oleg: Pour deux, seulement 20 minutes? Habituellement, lorsqu'il y a plusieurs personnes, le temps pour un rapport ne fait qu'augmenter.
Nikita: Nous avons parlé très vigoureusement et de manière animée de tous les sujets clés.
Oleg: Vanya, est-ce que cela a affecté votre décision sur la suite des choses? Travaillez-vous pour l'entreprise?
Ivan: C'est possible!
Oleg: C'est juste que les gens demandent généralement pourquoi assister à des conférences, des présentations, pourquoi écouter quelque chose, si vous pouvez le rechercher sur Google.
Nikita: Bien sûr, à mon avis, assister à une conférence est très utile. Lorsque vous avez un contact en direct, une participation directe, ce n'est pas du tout ce qu'il faut voir sur YouTube. Il est important que vous participiez directement et non virtuellement. Vous êtes en contact avec la source. La différence est à peu près la même que d'assister à un concert en direct ou de l'écouter sur un enregistrement. Probablement même grand, car combien pouvez-vous parler à votre artiste préféré après le concert? Mais lors de la conférence, vous pouvez trouver l'orateur dont vous avez besoin et lui demander tout ce dont vous avez besoin - il n'y a pas de problèmes.
Ivan: Soit dit en passant, concernant la décision de «rester dans l'entreprise», c'est une autre histoire. Nous avons un système de recrutement assez unique pour les employés / stagiaires. Nous prenons des stagiaires pour 2-3 cours, généralement de la faculté ou du département de physique. Les stagiaires sont très profondément plongés dans le sujet, les conservateurs les aident à comprendre les différents mécanismes de VM, les détails de mise en œuvre, etc. - ça coûte cher.
Après un certain temps, ils commencent à donner des missions de combat, à écrire du vrai code en production. Vous apportez des modifications à la JVM, passez par des revues, des tests, des benchmarks - vérifiez qu'ils ne sont pas affaissés. Vous vous engagez pour la première fois. Après cela, vous vous concentrez sur votre diplôme. Habituellement, un diplôme est également une partie intéressante de la recherche JVM, expérimentale. Cela est généralement fait par les étudiants. Ensuite, vous pouvez le produire - ou peut-être pas. Je n'ai jamais vu une telle chose si bien que tant de temps est consacré aux stagiaires. Et personnellement, je l'apprécie vraiment, car je me souviens du temps que j'ai passé sur moi. La sortie est un ingénieur JVM. Où d'autre est une telle usine sur la production d'ingénieurs JVM?
Oleg: Et vous n'avez pas peur des fuites d'informations des stagiaires, alors ils décriront ouvertement tout cela dans un diplôme?
Nikita: Ce n'est pas un problème, car nous avons peur d'une fuite à l'étranger, et surtout personne ne lira le russe - c'est une telle protection, une obscurcissement :-)
Ivan: J'avais un étudiant en défense cette année, j'étais le leader, et il y avait un tel problème que tout le monde ne voulait pas écrire dans un diplôme. Nous avons révélé quelque chose d'un sujet complètement fermé et, par exemple, un critique nous a demandé pourquoi nous ne parlions pas de certaines choses. Je lui ai dit que vous ne pouvez pas en parler, c'est très secret, nous ne pouvons pas. Ça l'est, je vais vous le dire à l'oreille, mais ça n'ira nulle part ailleurs. Nous avons donc un peu peur de cela, mais en général, vous pouvez trouver beaucoup de choses intéressantes dans les diplômes.
Oleg: Et comment chercher des diplômes impliquant Excelsior?
Nikita: Venez au bureau du doyen et demandez à lire un tel diplôme.
Ivan: Nous avons une liste de diplômes défendus avec succès sur notre site, mais seulement des noms, sans liens. Et nous n'en avons pas défendu sans succès.
Oleg: Ils meurent ou se défendent.
Ivan: Ça l'est! Nous avons un score moyen de 5,0 diplômés, il y a ceux qui ne vont tout simplement pas au diplôme.
Oleg: Dans cette formation, l'usine d'ingénieurs JVM, dites-nous quelles sont les étapes pour devenir Jedi? Quand ils vous donnent un sabre laser, quand pouvez-vous commencer à les agiter?
Nikita: Assez vite. Maintenant que les jeunes deviennent douloureusement rapides en Jedi, je suis fier d'eux.
Ivan: Soit dit en passant, Nikita a été mon premier conservateur lorsque j'étais stagiaire. Concernant le stage: vous passez d'abord par une sélection: vous résolvez des problèmes, venez à un ou plusieurs entretiens. Si tout va bien, vous devenez stagiaire. Dans un premier temps, vous lisez des articles scientifiques sur des sujets qui sont très probablement liés à votre futur diplôme, ou tout simplement sur des sujets JVM en anglais pour obtenir le contexte. Vous lisez, écrivez un essai sur eux, expliquez ce qui s'y passe. Ils sont très durs avec lui. Certains savants envieraient une telle relecture et une telle préparation de dissertation. Il s'avère que des articles à part entière en russe. Après cela, il est temps pour vous d'écrire le code, et vous êtes lentement présenté à l'essence de la question - comment tout cela fonctionne.
Nikita: Et c'est là que la science s'arrête.
Ivan: Pas nécessairement!
Nikita: C'est dommage, au début du zéro, nous avons publié des articles que nous avons apportés aux magazines ACM.
Ivan: Eh bien, nous le faisons maintenant, quel est le problème?
Nikita: Quel était notre dernier article dans le magazine ACM?
Ivan: Donc, dans ACM, nous n'avons tout simplement pas essayé! Maintenant, nous bloguons - c'est la même chose, seuls les gens le lisent. Il s'agit d'une activité similaire.
Revenant au sujet Jedi, après cela, la première fois que vous faites quelque chose en production sous un contrôle strict. Une petite tâche est nécessaire qui n'est pas liée à votre futur diplôme.
Oleg: Par exemple, écrire un commentaire.
Ivan: Non. Véritable fonctionnalité. L'étudiant doit apporter sa première réelle contribution pour qu'il reste dans le produit. , - , . , -, — . , . , JVM-.
: ? ? - , , - ? ?
: , . - — - , , , , , , JVM. , , , . , : « !». .
: JET?
: , JVM .
: - , JET — JET. , - , : baseline-. , . , , JET .
: ?
: , . , .
: - , baseline .
: , baseline JIT. , JIT , . , baseline. . - , baseline, .
: - UI-? .
: . . Windows.
: , . , Mac.
: Android ?
: . , Android Linux-, Linux . Linux Android . - . .
: ?
: ? Non.
: 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 ). , ? Mais rien. , - - , . JVM , . , .
Java . , , — . Loom Metropolis, Java. - JVM, , , , , . Loom , , . . , — .
. , Java — , 5-6 Java- JPoint . , Java- (Simon Ritter, Rafael Winterhalter). , Call for Papers 31 . . , YouTube. JPoint!