Des milliers de choses à corriger en Java à partir de la première version: une grande interview avec Sergey Kuksenko d'Oracle

Sergey Kuksenko est un ingénieur de performance qui a déjà vu Java version 1.0. Pendant ce temps, il a réussi à participer au développement d'applications mobiles, clientes, serveur et machines virtuelles. Depuis 2005, Java est engagé dans la performance et travaille actuellement chez Oracle pour améliorer les performances du JDK. L'un des conférenciers les plus populaires chez Joker et JPoint.

Cet habrapost est une grande interview avec Sergey, consacrée aux sujets suivants:

• Culte de la performance;
• Quand et ce qui doit être optimisé, la conception initiale de la langue et de la bibliothèque;
• Domaines prometteurs pour une optimisation supplémentaire;
• Comment participer au développement et ce qui peut être brisé par les optimisations;
• Astuces du compilateur, placement des registres;
• Est-il possible d'assembler un chat à partir de viande hachée;
• Lorsque les tests fonctionnent pendant cinq jours consécutifs et toute autre routine domestique;
• Comment devenir ingénieur de performance;
• Préparer un rapport pour le prochain Joker.

À propos du culte de la productivité

Oleg: Vous êtes notre ancien conférencier, et ce n'est pas notre première interview. Dites-moi un peu, qui êtes-vous maintenant, que faites-vous?

Sergey: Je suis le même qu'il y a de nombreuses années, et je fais la même chose. Je travaille dans l'équipe Java Performance et suis responsable des performances des machines Oracle Java, OpenJDK.

Oleg: Alors j'ai une question un peu troll: ici vous êtes un ingénieur de performance, et vos rapports portent sur toutes sortes de performances. Ne pensez-vous pas que le problème de performances est quelque peu surestimé? Tout le monde se précipite avec elle, mais est-ce même nécessaire?

Sergey: C'est une bonne question. Tout dépend de l'autre. Ce type d'attention du public peut être considéré comme excessif. La productivité des entreprises, en revanche, c'est de l'argent.

C'est le vrai argent que les gens dépensent en matériel, sur une sorte de cloud sur Amazon. Si vous ne traitez pas vos demandes assez rapidement - c'est tout, vous perdez des clients, perdez de l'argent, perdez tout le reste. Par conséquent, la demande de performance, bien sûr, est toujours là. La question est de savoir à quel point c'est important dans chaque cas. Je ne parle pas du trading haute fréquence.

Oleg: Au fait, pensez-vous que Java convient à cela?

Sergey: Avez-vous eu l'occasion de rencontrer une personne comme Peter Lawrey ?

Oleg: Qui est le PDG de Chronicle Software, les développeurs d'OpenHFT?

Sergey: Ceci est un ami très célèbre de Londres qui voyage beaucoup lors de conférences. Ils travaillent à Java dans le trading haute fréquence, ils vivent très bien.

Oleg: Le font -ils sur Java ou s'appelle-t-il du code natif de Java? Pourtant, il y a une différence.

Sergey: Je ne sais pas à ce niveau, il ne l'a pas dit. En principe, si vous le souhaitez, tout ce qui est nécessaire peut être réalisé en Java lui-même.

Oleg: Intéressant. Si vous prenez, par exemple, une communauté de pythonistes, ils ont beaucoup moins de culte de la productivité. Comment se fait-il que c'est exactement ce qui se passe dans notre communauté? Peut-être avez - vous provoqué le culte de la performance avec vos rapports? Vous, Shipilev, Pangin, Ivanov et ainsi de suite.

Sergey: Je ne sais pas comment c'est arrivé. Le culte de la productivité à la conférence russe est beaucoup plus élevé qu'à la conférence américaine. Peut-être que cela reflète le public lui-même. Chez nous, les gens veulent être plus engagés dans la productivité, c'est intéressant pour eux. Et en Amérique, ils veulent faire plus pour ce qu'ils paient plus. Mais c'est une hypothèse, une conjecture. Il en est ainsi.

Quand et ce qui doit être optimisé

Oleg: Vous avez dit qu'il y avait toujours une demande de performance. À quel moment devez-vous commencer à penser à la performance? Quand le tonnerre frappera-t-il?

Sergey: C'est une question abstraite générale. Il vaut mieux se tourner à nouveau vers le discours d’ Alexey Shipilev de l’une des conférences précédentes, où il a assez bien peint tout cela.

Oleg: Oui, je me souviens de la "courbe du nom Sh".

Sergey: Vous devez faire de la performance tout de suite, mais en fonction de quel niveau. Il n'est pas nécessaire d'écrire des repères immédiatement. Il est connu, par exemple, que la restriction banale du niveau d'architecture API entre Set as a set et SortedSet nous impose déjà des restrictions algorithmiques fondamentales.

Si nous avons poussé un SortedSet dans l'API (bien que personne n'ait besoin de ce tri), puis qu'il se soit répandu sur tout notre système, alors cette chose devra être retirée douloureusement et durement.

La question part du niveau même de conception - c'est une question de restrictions minimales. Les plus petites restrictions possibles doivent être utilisées pour que vous puissiez jouer avec elles plus tard. Par exemple, lorsque j'ai tordu divers morceaux de Java, des mots extrêmement mauvais me sont venus à l'esprit. Je voudrais faire quelque chose avec l'une des classes de base, mais je ne peux rien faire, car l'API est corrigée, vous ne pouvez plus la changer, elle a déjà rampé. Mais pour faire un tour et un overclocking, vous devez masquer certains détails.

Étude de cas: j'avais l'habitude de m'accroupir autour de la classe java.math.BigDecimal. Il y avait une grande demande de différents côtés pour le disperser d'une manière ou d'une autre. Il y a un cas assez bon et spécial lorsque notre BigDecimal n'est pas «Big», c'est juste Decimal, et vous devez les lire.

Maintenant, bien sûr, un emballage approprié a été créé pour cela. Mais s'il n'y avait pas de constructeur public sortant de BigDecimal, mais quelques méthodes et usines statiques, vous pourriez créer un résumé BigDecimal et cracher deux implémentations différentes qui fonctionnaient selon leurs besoins. Mais cela est impossible, car le constructeur ressort. Pour cette raison, vous devez déjà effectuer une vérification d'exécution inutile à l'intérieur, ce qui vous permet de suivre un chemin rapide dans certains cas.

Oleg: En résulte- t-il que lors du développement d'une bibliothèque standard, il vaut la peine d'abandonner les concepteurs et de faire des constructeurs partout?

Sergey: Il se fait tard.

Oleg: Si ce n'était pas trop tard, serait-ce une bonne idée?

Sergey: Elle donnerait plus de marge de manœuvre. Regardez: nous écrivons nouveau, et ce nouveau se tient en dehors du constructeur. On obtient deux opérations: d'abord on crée un objet, puis on appelle le constructeur qui le remplit. Et parfois, il serait très utile de cacher la création même de l'objet et de créer le mauvais objet que nous avons à l'extérieur. Il s'agit d'une restriction de langage, l'original, des premiers jours de Java.

Oleg: Eh bien, maintenant, tout le monde utilise des cadres DI qui vous permettent de tordre les proxys comme vous le souhaitez et d'ajouter quoi que ce soit, en contournant cette limitation. Dans la conception originale du langage, pourriez-vous ajouter quelque chose comme ça, le conteneur d'injection de dépendance intégré?

Sergey: J'ai une opinion très précise sur la conception initiale de la langue. Si vous vous souvenez de l'histoire de Java 1.0, il en est ressorti une pression temporelle assez sérieuse, tout devait être fait rapidement.

Il y a des milliers de choses que j'aimerais personnellement corriger depuis la toute première version. Mais je crains que même si un sur mille est choisi, un-deux-trois, et qu'ils auraient commencé à être fabriqués au moment du premier Java, alors Java ne serait pas sorti. Ceci est un exemple standard selon lequel le meilleur est l'ennemi du bien.

Quoi d'autre peut être optimisé en Java

Oleg: Les gens ordinaires ne peuvent réparer quelque chose que dans leur projet, et vous, en tant qu'ingénieurs de performance chez JDK, affectez immédiatement des centaines de milliers de projets. La question se pose: au cours de plus de 20 ans de développement Java, y a-t-il eu des domaines dans le JDK où l'intervention d'ingénieurs principaux peut avoir un effet notable? Et dans quelle mesure cet «effet perceptible» est-il perceptible?

Sergey: Premièrement, maintenant Java ne fonctionne plus du tout sur le matériel qui, disons, il y a 10 ans. Le fer maintenant et le fer il y a 10 ans sont deux grandes différences, et il est conseillé de faire différentes optimisations.

Deuxièmement, il est, bien sûr, merveilleux quand un ingénieur de la performance s'assoit et accélère quelque chose, obtient des nombres énormes, rend compte à ses supérieurs, frappe de l'argent pour un bonus après ces overclockings. Mais une énorme quantité de travail est en cours sur de nouveaux projets. Une fonctionnalité est ajoutée, et la tâche de l'ingénieur de performance n'est pas d'overclocker la fonctionnalité, mais de s'assurer que tout va bien dans cette fonctionnalité. Ou si ce n'est pas ok, alors trouvez une sorte de correction.

Oleg: Comment pouvez-vous en être sûr? Vous ne vérifiez pas le code officiellement. Qu'est-ce qu'un "assurez-vous"?

Sergey: S'assurer que tout va bien du point de vue de la performance est l'opinion subjective d'un ingénieur de la performance qui rédigera un rapport et dira que «tout est normal dans cette fonction». Selon la taille de la fonctionnalité, cela implique parfois beaucoup d'action, parfois beaucoup d'efforts différents. En partant du fait que vous avez juste besoin de vous asseoir bêtement, de regarder ce qui se fait là-bas, de comparer cette zone, de conduire des repères, de voir ce qui se passe à la sortie et de prendre une décision raisonnable et éclairée.

Oleg: Et du point de vue des performances et des nouvelles fonctionnalités - Java va-t-il généralement de l'avant? Y a-t-il quelque chose là-dedans? Parce que notre matériel n'a pas beaucoup changé, par exemple, si nous parlons d'Intel.

Sergey: Pour quelle période cela n'a-t-il pas changé?

Oleg: Par exemple, les 10 dernières années.

Sergey: Oui, y a-t-il un AVX-512 sur le matériel il y a dix ans?

Oleg: Non. Lui, probablement, n'est pas toujours présent dans le moderne?

Sergey: Certainement pas. Nous l'avons dans notre laboratoire, mais tout est occupé par des compilateurs. Ils se défoncent jusqu'à présent, donc je n'ai pas regardé.

Oleg: La prise en charge AVX-512 peut-elle être considérée comme un exemple de fonctionnalité typique?

Sergey: Probablement possible. Que dois-je faire exactement: nous avons eu une grande couche de travail sur le fait qu'il existe des exigences modernes pour ajouter de nouveaux algorithmes cryptographiques. C'est une chose où les algorithmes de cryptographie vieux de dix ans ne peuvent tout simplement pas être utilisés. Nous avons besoin de nouveaux algorithmes, de clés plus grandes. Et l'ajout de nouveaux algorithmes cryptographiques se produit, je dirais, en permanence.

Oleg: Accélèrent -ils en quelque sorte le matériel?

Sergey: Tout dépend des algorithmes spécifiques. Il existe des algorithmes très bien accélérés. Soit dit en passant, il y a 10 ans, cela n'aurait pas fonctionné sur le matériel Intel, mais environ 5-6 la façon dont les bonnes instructions sont apparues, jusqu'aux unités AES avec accélérations. Tout cela a été mis en œuvre avec un intervalle de temps minimum.

Oleg: Qu'en est-il du GPU, sont-ils également capables de multiplier les matrices?

Sergey: À propos du GPU - une conversation séparée. Nous avons pour cela un projet au Panama dans lequel tous ces travaux sont effectués, et un jour il atteindra la ligne principale de Java avec tous les goodies.

Oleg: J'ai quelques connaissances qui sont engagées, conditionnellement, en mathématiques financières. À partir d'un certain moment, ils passent toujours en C ++ pour l'informatique et affirment qu'il est très gênant d'utiliser toutes ces optimisations et ce matériel à partir de la plate-forme gérée. Cela peut-il être amélioré?

Sergey: Nous avons également une grande demande à ce sujet et il y a un certain nombre d'exigences internes. Par exemple, pour améliorer quelque chose dans le domaine de l'apprentissage automatique. En règle générale, il s'agit d'une multiplication de matrice banale, qui peut être rejetée sur le GPU. Le travail est en cours, disons-le.

Nous avons deux grands projets parapluie: Valhalla et Panama, qui devraient collecter des fonctionnalités comme le GPU. À la jonction de Valhalla et de Panama se trouve une API vectorielle qui fonctionne avec nos instructions SIMD / SSE / AVX directement à partir du code Java, et Valhalla lui-même avec des types en ligne est un grand pas dans cette direction.

Ce qui peut être brisé par l'optimisation, comment participer au développement

Oleg: Les parapluies que vous avez mentionnés sont similaires les uns aux autres. Est-il possible qu'un projet en affecte un autre, y compris en termes de code et de profil de performance? Par exemple, avez-vous refactorisé quelque chose et le malheureux Ron Presler, versant des larmes, fixe ses tests dans un coin du soir?

Sergey: Cela arrive tout le temps. Un exemple concret est l'API Vector. Pour que l'API Vector fonctionne correctement, nos vecteurs natifs doivent éventuellement devenir des types de valeur, ou comme on l'appelle maintenant en Java, des types en ligne. Vous pouvez faire un contournement dans le hotspot et l'implémenter d'une manière ou d'une autre, mais je veux avoir une solution générale. D'un autre côté, la caractéristique clé des types en ligne est précisément de ne pas se soucier de la disposition de ces données, et la disposition de ces données est extrêmement importante pour l'API Vector.

Parce qu'il correspond en fait directement à l'AVX-512 et tout ça. Il est clair que vous devez faire quelques squats, quelques optimisations, qui, d'une part, feront du type en ligne un type normal, mais qui auront une disposition matérielle. Naturellement, des intersections se produisent. Si vous regardez les groupes de personnes qui déplacent le Panama et déplacent Valhalla, ils se croisent plus de la moitié.

Oleg: Purement organisationnel, ici vous avez un projet, une sorte de problème de performance, mais il est à la jonction de plusieurs projets. Que faire ensuite? Comment résoudre ça? Il s'avère que c'est déjà un compromis entre les projets et les personnes, et non entre certaines tâches abstraites.

Sergey: Tout est très simple ici: s'il s'agit d'un problème de performances avec une fonctionnalité qui vient d'être conçue, vous devez vous adresser aux personnes qui conçoivent et dire: «Tellement et ainsi, qu'allons-nous faire? Faisons-le différemment. " La discussion commence et le problème est résolu.

Si le code existe déjà, il fonctionne déjà. Dans le cas idéal, vous résolvez ce problème ou, si vous ne pouvez pas le résoudre complètement, vous lâchez le prototype, puis vous revenez au propriétaire du code et dites: "Voici le prototype, que ferons-nous?" De plus, nous résolvons ce problème spécifiquement pour chaque cas.

Oleg: Nous avons ici des personnes intéressées qui ne peuvent pas participer à ce processus, ce sont des utilisateurs finaux.

Sergey: Ils ne peuvent pas participer suffisamment pour ne pas être payés pour leurs salaires chez Oracle. Si vous n'avez pas besoin d'un salaire, venez chez OpenJDK et participez.

Oleg: À quel point est-ce réel? OpenJDK a des putains de génies comme vous, et où les gens ordinaires sont, et où vous êtes. Disons que quelque chose ralentit pour moi, que dois-je faire et comment?

Sergey: Si vous ne connaissez pas le problème, il s'agit d'une question distincte, si quelqu'un va chercher une solution pour vous, c'est une question en tant que domaine, exemple, etc. Même si vous ne connaissez pas le problème, il est peut-être logique d'écrire dans OpenJDK et de demander. Si c'est quelque chose que quelqu'un clique immédiatement dans la tête, les gens l'attraperont. Si cela n'intéresse personne, il restera sans réponse.

Oleg: Supposons que je connaisse le problème et que je sache même ce qui doit être corrigé.

Sergey: Si vous connaissez le problème, vous venez chez OpenJDK, signez tous les morceaux de papier nécessaires, offrez un patch, il est révisé et versé.

Oleg: C'est aussi simple que ça?

Sergey: Eh bien, oui, un peu de bureaucratie, attendez un peu. Hier, Tagir ( lany ) a récupéré une petite correction que j'ai abandonnée. Il veut juste être amené à la fin. Il a commencé à y penser par lui-même. Il dit: "Merde, qu'est-ce que c'est, j'ai tout fait, mis en page, personne ne passe en revue." Eh bien oui, personne ne passe en revue. Nous sommes en juillet, la moitié du bureau Java est en vacances. Ils sortiront de vacances et le feront.

Oleg: Les vacances aux USA sont à peu près les mêmes dates que d'habitude en Russie?

Sergey: Non, le système de vacances aux États-Unis est complètement différent de celui de la Russie. Premièrement, ils sont nettement plus petits. Aux États-Unis également, le système de vacances est lié aux écoles. Lorsque vous avez des enfants en vacances - puis en vacances. Dès que les vacances commencent, toute l'Amérique commence à bouger. Et comme les cours se terminent ici à la mi-juin et commencent à la mi-août, ce delta pour les vacances n'est pas si grand - seulement deux mois.

Astuces du compilateur, placement du registre

Oleg: Est-il déjà arrivé que vous optimisiez quelque chose à la maison, et après cela, les utilisateurs devaient écrire du code différemment? Relativement parlant, si l'opération de sélection d'une sous-chaîne utilisait une plage et en fait maintenant une copie complète, cette refactorisation change la façon dont vous écrivez le code.

Sergey: Certainement, mais je ne vais pas donner d'exemples précis maintenant. La question est de savoir ce que les gens fixent lorsqu'ils écrivent du code. S'ils ont besoin d'extraire les performances maximales, et pour cela, ils font toutes sortes d'astuces spécifiques au compilateur, ils doivent être préparés pour que le compilateur évolue au fil du temps, et ils devront constamment modifier leur code en fonction de l'état actuel du compilateur. Et c'est super.

Supposons que, soudainement, après 20 ans, Graal devienne le compilateur principal de HotSpot - alors ces pauvres gars devront tout réécrire. Cela ne se produit que si vous avez assumé une telle tâche technique - suivre les changements dans le compilateur. Il est beaucoup plus simple d'écrire le code correct sans liens directs, avec des implémentations générales plus ou moins normales.

Soit dit en passant, sur les compilateurs - pas seulement sur les compilateurs Java, mais en général. Il y a la loi de Moore, qui n'est pas une loi, mais juste une observation empirique que le nombre de transistors double tous les ans et demi.

Et il existe exactement la même loi (loi de Proebsting ) selon laquelle les performances du code sans modification augmentent de 4% tous les un an et demi à deux ans. Ces 4% sont ce que les utilisateurs finaux obtiennent gratuitement uniquement grâce à l'évolution des compilateurs. Pas du matériel, à savoir des compilateurs.

Oleg: Je me demande d'où viennent ces pourcentages. Est-ce une sorte d'inefficacité initiale? Mais un jour, ce stock d'inefficacités prendra fin.

Sergey: Non, c'est juste une question de développement technologique. J'ai quitté les compilateurs lorsque j'ai commencé à travailler sur les performances. Mais une fois que j'étais fiancée, et la plus grande découverte pour moi a été faite en 2005 ou 2006. Je l'ai découvert du tout en 2008 parce que je n'avais pas lu l'article à temps.

Une tâche très importante de toute génération de code est l'allocation des registres. Il est connu qu'en général, ce problème est NP-complet. Il est très difficile de le résoudre, et donc tous les compilateurs essaient de piloter une sorte d'algorithme approximatif avec différents degrés de qualité.

Et voici un article où les gars prouvent que dans certains cas qui couvrent un grand nombre de compilateurs et un grand nombre de représentations internes avec certaines restrictions, un algorithme polynomial exact existe pour la tâche d'allocation d'allocation de registre. Hourra, allons-y!

Cela s'est produit en 2005, les compilateurs réalisés plus tôt ne le savaient pas.

Oleg: Vous pouvez maintenant créer un nouvel allocateur pour Java?

Sergey: Maintenant qu'il existe une solution théorique, elle peut être réécrite. Je ne suis pas entré dans les détails, mais je sais que les gars d'Excelsior ont implémenté l'algorithme.

Oleg: Nous avons récemment fait une interview avec Cliff Click, et il a parlé de l'allocateur de génie incroyablement complexe et fou qu'il a écrit pour Java. Vous ne voulez pas en écrire un autre?

Sergey: Non.

Oleg: Y a - t-il quelque chose de normal?

Sergey: Non, il n'est pas normal. De mon point de vue utilitaire, je dirai que je regarde en assembleur et parfois je vois: "Eh bien, oui, ici les registres ont mal tourné". Si je recourt à botter nos compilateurs, et que nous réécrivons l'allocateur, qu'allons-nous obtenir? Nous obtiendrons un gain, mais je ne le verrai probablement pas, sauf dans les exemples où j'ai vu l'allocation inefficace des registres. Tant qu'il n'y a pas de gros échecs dans ce domaine, il y a toujours quelque chose à faire et à gagner plus de gains.

Oleg: Y a-t-il des domaines de travail dans le JDK où tout le compilateur du compartiment moteur ou la magie des performances fait surface? Vous dites que vous devez écrire du code normal normal et tout ira bien, mais cela semble suspect.

Sergey: Tout ira bien jusqu'à ce que vous ayez besoin d'un super duper. Si vous en avez besoin très rapidement, soyez prêt à toujours le réécrire. Pour le moment, si vous prenez une grande application abstraite, dans l'ensemble, telle qu'elle est écrite - ne joue généralement pas de rôle en termes de performances.

D'une part, dès que le garbage collector est déclenché, il mange ses 10-20%, d'autre part, l'architecture de l'application commence à apparaître. L'énorme problème que j'ai vu dans le tas d'applications est qu'elles transfèrent des données. On a pris les données d'ici, on les a transférées là-bas, on y a fait des transformations. En général, tout programme fait exactement cela. Il transfère les données d'un endroit à un autre d'une manière ou d'une autre. Mais si vous avez trop de changements dans le programme, le compilateur n'aidera pas.

Oleg: Vous pouvez essayer de suivre des choses simples, comme: ce morceau de mémoire change de propriétaire et se déplace entre les objets dans cette direction.

Sergey: Non, c'est un problème de conception. Mais je ne change pas seulement, mais je change avec des modifications, je fais quelque chose avec eux. Le plus grand avantage dans les applications réelles et massives peut être obtenu si vous y réfléchissez: y a-t-il tellement de changements nécessaires. Au lieu de dix, faire sept est déjà bon.

(Il pourrait sembler que la même vidéo a été accidentellement dupliquée ici. En fait, tout est plus simple, Habr a mis en cache la mauvaise image de YouTube)

Nous collectons un chat à partir de viande hachée

Oleg: Nous venons d'avoir une conférence Hydra sur l'informatique distribuée. Et tant de gens se soucient beaucoup de choses comme un modèle de coût, déterminant le coût de chaque opération - très granulaire, très précis. Les gens veulent vraiment écrire toutes les instructions, additionner le coût de chacune d'entre elles et voir combien de barres votre code prendra. Je me demande comment cette approche fonctionne dans la réalité moderne. , ?

: , . , . , . , . , , , . ?

: : « ».

: , . , . , ? . — , . , , - , .

: , ?

: , ? , . ?

: , - ?

: , — , . - . ? , , , , . , .

: .

: , 1 . , , . , - , - .

performance-

: OpenJDK . ? C++ . — -?

: , , . . OpenJDK 15 . 15 .

: , , . .

: ! , , . , , , , , . , . : , , ( , ), — . , , .

: , ?

: , , Java.

: ?

: , , Valhalla.

: - , , — , ? ? .

: , . — . , , , . , , . . 2-3 , , , , — , .

, , inline-, Java Joker. . , Java- , runtime-. red flag: runtime- 0. ? , out of order- — .

, . , . ? . . baseline, , 5-6 , — . , , - 2 — - . 3% - , . 3% ?

: , ?

: , . performance-, . , , — .

, , . performance- — , - performance- - , . , , .

, , , , performance- — class libraries hotspot, .

«» performance

: , - performance-, . , , ?

: . ? , performance- performance-.

, : , , Oracle, Twitter, Netflix , - . , — . , performance- , .

- , , performance- , ? , , .

, performance- — . : - performance review, , , , , . — performance .

: « , ...», , — . , - — , , , .

Joker

: Joker . ?

: inline-, .

: , value-?

: , , . . , . value Java- . value, value, by value, - by value, value type. , .

. , , , Rémi Forax - , inline-. , , Kotlin inline- , value- Java, .

. value-, , , mvt (minimum value types), LW 1. LW 2 — , . , , , . , , , , performance- , , , , .

: , - -?

: , - . , , , , invokedynamic .

: , , , , .

: , , , . — , , . , ?

: , , , .

: . , , inline- generic- , inline-. , .

: , - ?

: : inline- LW2 . value-, generic, .

« Java -? Valhalla» Joker , - 25-26 2019 . , .