AdoptOpenJDK et Alibaba ont annoncé que le JDK Dragonwell d'Alibaba sera construit, testé et distribué à l'aide de l'infrastructure d'AdoptOpenJDK. Cela signifie que les utilisateurs ont plus d'options et peuvent choisir d'utiliser Dragonwell en raison de ses fonctionnalités uniques telles la prise en charge des coroutines et warmup.
Dragonwell d'Alibaba est une version downstream d'OpenJDK, qui possède des fonctionnalités importantes qui ne sont pas disponibles dans la ligne principale d'OpenJDK. Alibaba le décrit comme une version d'OpenJDK optimisée pour les applications de commerce électronique, financières et logistiques. Alibaba utilise Dragonwell pour exécuter ses applications sur plus de 100 000 serveurs.
En 2019, Dragonwell a été rendu open source et il est disponible gratuitement. Linux x86-64 est officiellement pris en charge, cependant, il existe également une version aarch64 disponible et une version expérimentale pour Windows. Alibaba mentionne qu'il fournira un support à long terme, mais la période exacte n'a pas été définie.
Les builds pour Dragonwell 8 et 11 seront publiés sur le site Web AdoptOpenJDK. Cela signifie que l'API AdoptOpenJDK peut être utilisée pour télécharger les binaires. Ceci est particulièrement utile pour les organisations qui automatisent la récupération de nouveaux binaires.
L'une des fonctionnalités uniques de Dragonwell est JWarmup. JWarmup essaie de réduire les problèmes de performances liés au préchauffage causés par la compilation JIT. La solution utilise la précomplation des hot méthodes pour améliorer les performances. Pour y parvenir, deux phases sont définies : pré-exécution (pre-run) et exécution normale (normal run).
Dans la phase de pré-exécution, les données de profilage des hot méthodes sont enregistrées pendant un test de charge et stockées dans un fichier sur disque. Ce fichier est utilisé pendant l'exécution normale où le thread JIT compile les méthodes du fichier en versions natives. Désormais, ces méthodes sont exécutées nativement au démarrage au lieu d'être interprétées. Cela réduit la phase de warmup d'une application, ce qui améliore les performances des applications qui viennent de démarrer.
Ces types d'idées pour réduire les effets de warmup font l'objet de discussions depuis de nombreuses années - par exemple, Azul Systems a une technologie dans sa JVM Zing appelée ReadyNow! qui réutilise également les données de compilation des exécutions précédentes. L'ajout de la compilation à plusieurs niveaux (tiered compilation) et du compilateur jaotc représente également des étapes dans le sens de l'amélioration des performances de démarrage en réduisant ou en contournant la quantité de mode interprété qui est exécuté.
Une autre fonctionnalité intéressante est le support de la coroutine Wisp2. Wisp2 mappe les threads Java aux coroutines au lieu des threads au niveau du noyau. Les performances de l'application sont potentiellement améliorées car de nombreuses coroutines peuvent être planifiées sur un petit nombre de coeurs. Cela réduit la surcharge de planification et peut montrer une amélioration en fonction de la charge de travail en cours d'exécution.
Le moteur Wisp2 est similaire à certains égards aux objectifs du projet Loom, qui tente également de supprimer le goulot d'étranglement du nombre de threads en direct en permettant aux développeurs de «virtualiser» leurs threads et de les multiplexer sur un plus petit nombre de threads de la plate-forme utilisant des approches similaires aux coroutines.
L'idée centrale de Wisp2 est que (contrairement à Loom), il fonctionne out of the box sur le code existant en l'activant avec ces arguments de la JVM :
java -XX:+UnlockExperimentalVMOptions -XX:+UseWisp2
Comme Wisp2 ne nécessite aucune modification du code source, le coût de migration est faible. Les développeurs n'ont pas besoin d'implémenter eux-mêmes les coroutines et les fonctionnalités de concurrence Java existantes peuvent toujours être utilisées.
Cependant, toutes les applications ne bénéficient pas de Wisp2 et l'impact du déplacement automatique de tous les threads vers les coroutines peut être très important (et pas nécessairement positif).
Les applications qui utilisent de manière intensive des I/O où les tâches sont bloquées sur des événements puis planifiées peuvent bénéficier du support des coroutines. D'un autre côté, les applications gourmandes en CPU ne bénéficieront probablement pas des coroutines. Le moyen le plus simple de savoir si une application bénéficie de Wisp2 est d'activer le support et d'exécuter un test de performances.
Alibaba travaille activement à la contribution de ces fonctionnalités et autres correctifs dans OpenJDK upstream. Par exemple, JWarmup est décrit dans une proposition d'amélioration Java (JEP), mais qui est toujours à l'état de brouillon au moment de la rédaction.
AdoptOpenJDK et Dragonwell d'Alibaba sont deux des distributions les plus connues basées sur OpenJDK, mais il existe de nombreuses autres options telles que : Corretto d'Amazon, SapMachine de Sap, Liberica de BellSoft, Zulu d'Azul et ojdkbuild. Ces organisations fournissent des JDK et des JRE avec différentes fonctionnalités et correctifs. À côté de cela, chaque organisation détermine ses propres niveaux de support, dont certains sont payants. Cela donne aux clients plus de liberté car ils peuvent choisir leur JDK préféré en fonction des fonctionnalités et du support dont ils ont besoin.
Mise à jour : référence corrigée vers le statut du TCK de Dragonwell d'Alibaba