Courant mars 2024, une proposition, basée sur JEP 197: Segmented Code Cache et JEP 165: Compiler Control a été publiée sur openjdk.org. L'idée de cette proposition est d'étendre le cache de code segmenté avec un nouveau tas de code « chaud » facultatif pour accueillir de manière compacte une partie des méthodes non profilées, ceci afin d'améliorer l'exécution de code Java. L'idée est aussi d'étendre le mécanisme de contrôle du compilateur pour marquer certaines méthodes comme étant chaudes afin qu'elles soient compilées dans le tas de code chaud. Par code chaud on entend du code fréquemment exécuté au sein d'une application.

Le mécanisme permettra ainsi d'isoler le code qui est connu pour être chaud et de ce fait réduira il réduira la fragmentation du code optimisé. La proposition par du constat suivant :

Certaines applications peuvent perdre leurs performances en raison de l'énorme cache de code JVM. Cela se produit si plusieurs conditions sont remplies :

1. Une grande partie du code a été compilé par le compilateur JIT (des centaines de mégaoctets, des gigaoctets).
2. Il existe une grande quantité de code chaud.
3. Le code vraiment important (chaud) est dispersé dans le cache de code.
4. Le processeur se trouve pénalisé pour l'exécution de grandes quantités de code dispersé.

L'auteur de la proposition souligne que sur les systèmes où ce problème est important, il ne peut pas être résolu actuellement par d'autres moyens tels que des pages volumineuses. Il souligne encore que le ralentissement dépend de la quantité de code chaud, de sa rareté et du type de processeur. Ce ralentissement simulé dans les benchmarks peut atteindre des dizaines de pour cent.

La proposition ne vise pas une version spécifique de Java. Il n'est toutefois pas impossible qu'une première implémentation de prévisualisation de ce tas de code chaud arrive avec Java 23 qui sortira en septembre.

Site : openjdk.org/jeps/8328186