Après le passage d'un service JVM aux threads virtuels, qu'est-ce qui a changé en matière de débit, de mémoire et d'incidents de pinning, et qu'a-t-il fallu réécrire ?

Question ouverte

La JEP 444 a introduit les threads virtuels dans Java 21 et décrit les situations où un thread virtuel est épinglé (pinned) à son thread porteur (carrier), par exemple lorsqu'il s'exécute dans un bloc synchronized ; elle précise que le pinning ne rend pas une application incorrecte mais peut nuire à sa scalabilité. La JEP 491, livrée dans JDK 24, modifie l'implémentation de synchronized afin que les threads virtuels qui y bloquent libèrent leur thread porteur. L'intention de conception est claire : un serveur à un thread par requête peut cesser de dimensionner un pool de threads de plateforme et laisser chaque requête s'exécuter sur son propre thread bon marché. Ce que le wiki ne dit pas encore, c'est ce qui s'est passé lorsque des services réels ont opéré ce basculement.

Pour un service ayant fait passer le traitement de ses requêtes, ou ses appels sortants, d'un pool de threads de plateforme borné à des threads virtuels : le débit sur le même matériel a-t-il augmenté, est-il resté stable, ou a-t-il baissé, et à quel niveau de concurrence ? Qu'est-il advenu de la mémoire heap et off-heap lorsque le nombre de requêtes simultanément actives n'était plus plafonné par un pool ? Quels incidents s'en sont suivis : pinning du thread porteur sous un bloc synchronized dans un pilote ou une bibliothèque de journalisation, épuisement d'un pool de connexions en aval qui était auparavant protégé par la taille du pool de threads, caches thread-local multipliés par des milliers de threads, ou interblocages que l'ancien pool masquait ? Quelles bibliothèques ont dû être mises à niveau ou remplacées, et le changement apporté par JDK 24 a-t-il suffi à supprimer les contournements du pinning ? L'équipe a-t-elle conservé quelque part un sémaphore borné pour remplacer la contre-pression (back-pressure) que fournissait auparavant le pool, et comment sa taille a-t-elle été choisie ?

La réponse importe parce que cette migration est souvent présentée comme un simple changement de drapeau, alors que le pool qu'elle supprime remplissait plus d'un rôle.

Ce qu'une réponse utile contient

La version du JDK avant et après, le framework et le serveur, les pilotes et clients présents sur le chemin de la requête, et la charge de travail (taux de requêtes, répartition entre attente d'E/S et CPU). Les débits et les percentiles de latence sous la même charge avant et après, avec la méthode de génération de charge et le nombre d'exécutions. Les mesures de mémoire (heap, metaspace, native) à charge égale. Une liste des événements de pinning observés (le JDK peut les signaler) avec la bibliothèque responsable et le correctif appliqué. Les incidents attribués à la migration, avec leur mécanisme. Les modifications de code nécessaires, en particulier les remplacements de la contre-pression fondée sur le pool et de l'état thread-local. Un rapport ne constatant aucune différence mesurable est tout aussi utile qu'un rapport en constatant une importante, à condition que la charge et la méthode de mesure soient précisées.