Alors que Java 9 approche du jalon de disponibilité générale, maintenant prévue pour le second trimestre 2017, un grand nombre de JEPs structurantes commencent à assumer leur forme finale. La caractéristique clé est sans doute la JEP 261 (système de modules) qui propose la mise en œuvre du Système de Modules de Plateforme Java tel que spécifié dans la JSR 376. La JEP Système de Modules dépend de la JEP 260 (encapsulation de la plupart des API internes) dont le résultat sera d'exposer la fonctionnalité de la classe controversée sun.misc.Unsafe par des références de variable telles que définies et ciblées par la JEP 193. InfoQ a précédemment couvert les préoccupations de la communauté sur la gestion de sun.misc.Unsafe (avant la JEP 260) et a présenté une couverture détaillée du plan de migration possible (après la mise en œuvre de la JEP 260).
Le bug 8149159 a été récemment publié sur le Système d'Anomalie du JDK, proposant des optimisations et des nettoyages pour Unsafe, y compris le déplacement de la vérification depuis la couche native vers Java (de le simplification JIT), l'unification de sun.misc.Unsafe avec jdk.internal argument. misc.Unsafe et un nettoyage général du code natif.
Le 18 février, l'ingénieur Mikael Vidstedt d'Oracle a soumis deux patchs (un pour l'OpenJDK et un autre pour la VM HotSpot d'OpenJDK) pour revue à la communauté des développeurs OpenJDK.
Vidstedt a résumé les patchs comme suit :
Afin d'éviter la duplication de code, sun.misc.Unsafe délègue désormais tout son travail à jdk.internal.misc.Unsafe. Cela signifie également que la VM - et unsafe.cpp spécifiquement - n'a plus besoin de savoir ni de se soucier de s.m.Unsafe.
Les méthodes de délégation de s.m.Unsafe ont toutes été décorées avec @ForceInline pour minimiser le risque de régressions de performance, mais il est fort probable qu'elles seront linéarisées même sans les annotations.
La documentation a été mise à jour pour indiquer qu'il est de la responsabilité de l'utilisateur de Unsafe de s'assurer que les arguments sont valables.
La vérification d'argument a, dans la mesure du possible, été déplacée de unsafe.cpp à Java pour simplifier le code natif et permettre au JIT de l'optimiser.
Certains des contrôles d'arguments ont été assouplis. Par exemple, l'U.copySwapMemory récemment introduit ne vérifie plus les pointeurs nuls. Référez-vous à la documentation de j.i.m.U.checkPointer pour le raisonnement complet derrière tout ceci. Notez que les méthodes d'Unsafe, en dehors d'U.copySwapMemory, n'effectuent plus aujourd'hui la (les) vérification(s) liée(s) à NULL.
Un test a été ajouté pour j.i.m.U.copyMemory, basé sur U.copySwapMemory. N'hésitez pas à me dire si je devrais les fusionner (parce que je devrais).
Selon Vidstedt, le nettoyage d'Unsafe était "plutôt dramatique" et il a souligné ce qui suit :
Unsafe_functions sont maintenant déclarées statiques, comme le sont les autres fonctions locales unsafe.cpp.
Création d'unsafe.hpp et déplacement de certaines fonctions utilisées dans d'autres parties de la machine virtuelle dans celui-ci. Suppression des déclarations de fonction "extern" (extern est mauvais, des chatons meurent quand extern est (sur-)utilisé).
Suppression du commentaire effrayant à propos de UNSAFE_LEAF qu'il n'est pas possible d'utiliser - il n'y a rien de spécial à ce sujet, il s'agit juste d'un JVM_LEAF.
Utilisation d'UNSAFE_LEAF pour quelques méthodes leaf simples.
Ajout d'accolades utiles autour de UNSAFE_ENTRY / UNSAFE_END pour aider l'auto-indentation.
Suppression de quelques 140 fonctions/macros dans Unsafe _ <...> ##.
Mise à jour des noms d'argument de macro pour être cohérent au travers des définitions de macro d'unsafe.cpp.
Remplacement de quelques vérifications par des assertions - comme ci-dessus, les contrôles sont maintenant effectués dans j.i.m.Unsafe.
Suppression de tout le code lié à s.m.Unsafe.