L'API Foreign Function & Memory (FFM) a été initialement proposée comme fonctionnalité d'aperçu par JEP 424 (JDK 19), puis affinée par les JEP JEP 434 (JDK 20) et JEP 442 (JDK 21). Une nouvelle JEP, 454, finalise cette API FFM qui sera intégrée à Java 22 en version stable.

Fonctions étrangères

Du côté des fonctions étrangères (Foreign Function), l'objectif est de remplacer la machinerie fragile des méthodes natives, ainsi que l'interface native Java (JNI), par une API concise, lisible et purement Java. Ceci avec des performances comparables, sinon meilleures que celles de JNI. Cette API a également pour ambition de garantir l'absence de bogues d'utilisation après libération, même lorsque la mémoire est allouée et désallouée sur plusieurs threads. Elle veut également fournir des moyens uniformes d'opérer sur des données structurées et non structurées, de taille illimitée, dans plusieurs types de mémoire (par exemple, mémoire native, mémoire persistante et mémoire de tas gérée).

Mémoire

Les objets créés via le mot-clé new sont stockés dans le tas de la JVM, où ils sont libérés par le ramasse-miettes (garbage collection) lorsqu'ils ne sont plus nécessaires. Cependant, explique la JEP, le coût et l'imprévisibilité du garbage collection sont inacceptables pour les bibliothèques critiques en termes de performances telles que Tensorflow , Ignite , Lucene et Netty. De telles bibliothèques doivent pouvoir stocker les données en dehors du tas, dans une mémoire hors tas qu'ils allouent et désallouent eux-mêmes. L'accès à la mémoire hors tas permet également de sérialiser et de désérialiser les données en mappant les fichiers directement dans la mémoire via, par exemple.

La plate-forme Java a historiquement fourni deux API pour accéder à la mémoire hors tas : l'API ByteBuffer et l'API sun.misc.Unsafe, chacune souffrant de limitations et de défauts. Les développeurs sophistiqués, estime la JEP, méritent une API capable d'allouer, de manipuler et de partager de la mémoire hors tas avec la même fluidité et la même sécurité que la mémoire sur tas. Une telle API devrait équilibrer le besoin d'une désallocation prévisible avec la nécessité d'empêcher une désallocation prématurée, ce qui peut conduire à des pannes de la JVM ou, pire encore, à une corruption silencieuse de la mémoire.

Cette API s'articule autour des notions de segments de mémoire et d'arènes (Arena), ces dernières contrôlant le cycle de vie des segments de mémoire native, offrant à la fois une allocation flexible et une désallocation rapide. Tous les segments de mémoire fournissent des limites spatiales et temporelles qui garantissent la sécurité des opérations d'accès à la mémoire. Autrement dit, ces limites garantissent aucune utilisation de mémoire non allouée et aucune utilisation après libération.