Une proposition anime actuellement la communauté Java autour de l'utilisation d'une accélération matérielle en vue d'améliorer les calculs en bloc dans cette plateforme. Baptisé Trinity, ce projet permettrait l'amélioration de l'exécution des calculs d'agrégats en vrac sur Streams, en déchargeant les calculs sur les accélérateurs matériels. Streams dans Java propose aux développeurs d'effectuer des calculs exploitant efficacement le parallélisme des données. La fonctionnalité Stream dans Java Standard Edition 8 est destinée au traitement des données déclaratives et tire parti des architectures multicœurs. « Ces calculs sont les principaux candidats pour tirer parti des instructions améliorées basées sur les données CPU, telles que SIMD ou le déchargement sur les accélérateurs matériels, tels que le co-processeur SPARC Data Accelerator », a déclaré Karthik Ganesan, architecte et ingénieur principal chez Oracle, vendredi dans un forum de discussion OpenJDK.
Le projet explorerait comment les bibliothèques comme Streams peuvent être améliorées pour utiliser des fonctionnalités matérielles de traitement plus efficace des données. La réussite serait mesurée en fonction de l'amélioration de la vitesse et de l'efficacité des traitements, mais aussi de la facilité d'utilisation de l'accélération matérielle. Trinity explore également la possibilité de construire une bibliothèque optimisée pour décharger les données vers des accélérateurs matériels ou un GPU optimisé pour le compilateur Graal pour transformer automatiquement les pipelines Streams appropriées et utiliser les fonctionnalités matérielles de traitement de données.
Des commentaires mitigés
Les votes de la communauté concernant Trinity sont attendus avant le 4 mai, mais les premiers commentaires sur la proposition sont mitigés. Une personne sur la liste de diffusion a suggéré d'utiliser le Projet Sumatra existant, qui vise à permettre aux applications Java de profiter des GPU, pour les objectifs proposés par Trinity. Ce à quoi Karthik Ganesan a répondu que Sumatra concernait la traduction d'un code d'octet pour s'exécuter sur un GPU, alors que Trinity l'était sur les API pour les opérations analytiques, qui peuvent être déchargées aux accélérateurs. Un autre commentaire a suggéré que Trinity prenne également en compte Project Panama lié à l'interconnexion de la JVM et du code natif.