Je parle de gc particuliers pour du temps réel, pour ne pas avoir de problème de temps de réponse les gc inclus dans openjdk font le travail. Non seulement ils font la majorité de leur travail sans bloquer ton application, mais en plus ils ont des options pour les contraindre en temps et en fréquence d'exécution.
Après tu as le tuning de jvm indépendent du gc. Tu peux dimensionner les générations et spécifier des configurations pour que les étapes du gc s'exécutent au moment opportun (ça n'est pas programmatique et impératif avec System.gc()).
Si tu te pose la question de frame de temps, c'est que tu contrôle finement tes allocations et tu va t'assurer que tes objets sont soient en old gen, soit qu'ils soient en young gen. Ta young gen est dimensionnée pour une seule de tes frame et le gc s'exécutera une fois par frame systématiquement et jamais plus que le temps que tu lui as donné. Son temps pour nettoyer ta young gen est tout à fait prédictible. C'est du grosse maille (oui faire du temps réel même soft c'est un métier), mais le gc peut t'expliquer quand il a fait quoi et pourquoi ça couplé aux autres possibilités d'observabilité de la jvm t'es pas laissé tout seul pour te dépatouiller et comprendre ce qu'il se passe.
Il a bon dos le gc, pas mal de fois où je vois le gc mis en cause il y a surtout des io synchrones utilisées un peu de partout et on essai de gagner 10ms de temps en temps sur le garbage collection sans s'inquiéter des 100ms de blocage fréquent dû à une io. Pour l'asynchrone c'est déjà bien plus hard de s'y retrouver, je sais qu'il y a un outil qui peut te prévenir si ton code sur la jvm fais des io bloquantes mais l'asynchrone peut rendre un code complexe et surtout fait perdre en prédictabilité des performances. Garantir que tu réponds sous un certain seuil demande à avoir des timeouts sur tout ce qui est asynchrone par exemple (du coup async/await t'aident plus beaucoup).
Désolé je suis un peu fleuve c'est pour rentrer un peu dans le détail et montrer l'approche. Il est bien sûr possible de faire mieux en faisant tout à la main, mais tu troque un contrôle plus simple (au sens KISS) pour un outillage très riche qui t'aide énormément à comprendre ce qui se passe. Le plafond indépassable en java ne semble pas à la portée de la première application même s'il existera toujours (mais est repoussé régulièrement encore l'an dernier avec zgc et Shenandoah).
En plus de ça tu peux toujours ne pas mettre les objets les plus volumineux dans la heap. Les assets sont volumineux et peuvent avoir des cycles de vie simples (on les charges et les libèrent à des points clefs) et ça permet de rester sur la simplicité d'usage pour le gros du code (celui qui est complexe, qui gère la partie logique de l'application) qui va interagir avec un gestionnaire d'assets qui sait quand charger/libérer les gros volumes. Ça marche aussi en utilisant un gc en bibliothèque en rust ou c++.
[^] # Re: Ne pas craindre la Faucheuse
Posté par barmic 🦦 . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été. Évalué à 3.
Je parle de gc particuliers pour du temps réel, pour ne pas avoir de problème de temps de réponse les gc inclus dans openjdk font le travail. Non seulement ils font la majorité de leur travail sans bloquer ton application, mais en plus ils ont des options pour les contraindre en temps et en fréquence d'exécution.
Après tu as le tuning de jvm indépendent du gc. Tu peux dimensionner les générations et spécifier des configurations pour que les étapes du gc s'exécutent au moment opportun (ça n'est pas programmatique et impératif avec System.gc()).
Si tu te pose la question de frame de temps, c'est que tu contrôle finement tes allocations et tu va t'assurer que tes objets sont soient en old gen, soit qu'ils soient en young gen. Ta young gen est dimensionnée pour une seule de tes frame et le gc s'exécutera une fois par frame systématiquement et jamais plus que le temps que tu lui as donné. Son temps pour nettoyer ta young gen est tout à fait prédictible. C'est du grosse maille (oui faire du temps réel même soft c'est un métier), mais le gc peut t'expliquer quand il a fait quoi et pourquoi ça couplé aux autres possibilités d'observabilité de la jvm t'es pas laissé tout seul pour te dépatouiller et comprendre ce qu'il se passe.
Il a bon dos le gc, pas mal de fois où je vois le gc mis en cause il y a surtout des io synchrones utilisées un peu de partout et on essai de gagner 10ms de temps en temps sur le garbage collection sans s'inquiéter des 100ms de blocage fréquent dû à une io. Pour l'asynchrone c'est déjà bien plus hard de s'y retrouver, je sais qu'il y a un outil qui peut te prévenir si ton code sur la jvm fais des io bloquantes mais l'asynchrone peut rendre un code complexe et surtout fait perdre en prédictabilité des performances. Garantir que tu réponds sous un certain seuil demande à avoir des timeouts sur tout ce qui est asynchrone par exemple (du coup async/await t'aident plus beaucoup).
Désolé je suis un peu fleuve c'est pour rentrer un peu dans le détail et montrer l'approche. Il est bien sûr possible de faire mieux en faisant tout à la main, mais tu troque un contrôle plus simple (au sens KISS) pour un outillage très riche qui t'aide énormément à comprendre ce qui se passe. Le plafond indépassable en java ne semble pas à la portée de la première application même s'il existera toujours (mais est repoussé régulièrement encore l'an dernier avec zgc et Shenandoah).
En plus de ça tu peux toujours ne pas mettre les objets les plus volumineux dans la heap. Les assets sont volumineux et peuvent avoir des cycles de vie simples (on les charges et les libèrent à des points clefs) et ça permet de rester sur la simplicité d'usage pour le gros du code (celui qui est complexe, qui gère la partie logique de l'application) qui va interagir avec un gestionnaire d'assets qui sait quand charger/libérer les gros volumes. Ça marche aussi en utilisant un gc en bibliothèque en rust ou c++.
Bref j'ai pas été bref
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll