C'est ce que je dis, il me semble. C'est juste que quand tu arrives à la situation problématique cela revient plus ou moins à cela (un mark&sweep).
Non carrement pas. En fait on arrive à faire des full GC qui sont presque entièrement concurrents et parallèles. D'un point de vu jitter pour l'application, le full GC n'est pas pire qu'un minor GC, ca va juste occuper plus du CPU et pourrir temporairement tes caches CPU.
Par contre tu as quelques phases qui sont bloquantes, mais qui arrivent aussi en minor collection, et dont le temps d'exécution va dépendre de la tête de ta oldgen. Notament de sa fragmentation et de l'état des dirty cards. Ce qui fait que le full GC est rarement un problème, par contre tes performances se dégradent lentement jusqu'à ce qu'un full GC arrive.
Quand tu as ce genre de problèmes en général soit tu configures ton GC pour être aggressif et déclancher des full GC très tôt, soit tu forces des full GC reguliers via JMX. Les deux sont crados mais ca fait le job.
Je suis assez d'accord avec :
Je suis pas foncièrement en désaccord non plus. J'ai pas regarder rust en détail mais leur approche semble pas mal non plus.
Après je reste pragmatique par rapport aux outils actuellement disponibles et leur facilité d'utilisation/déploiement. Et surtout je n'oublie pas que je peux écrire du Java comme du C pour la gestion mémoire: je peux faire des alloc manuelle, je peux gérer mes alignements, je peux gérer ma contiguité etc.
La question qui se pose est donc:
- Quel est le meilleur outil pour écrire la majorité du code
- Puis-je atteindre les perfs visées pour le code qui a besoin d'être performant ? Exemple: Si j'ai besoin de SIMD Hotspot ne tient pas la route, mais je peux aussi sortir du C++ pour les 100 lignes de code qui en ont besoin ou tout faire en C++.
Maintenant si j'écrivais un jeu, je ne ferais clairement pas les mêmes choix que pour écrire du code backend.
[^] # Re: la réponse est évidente
Posté par ckyl . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 3.
Non carrement pas. En fait on arrive à faire des full GC qui sont presque entièrement concurrents et parallèles. D'un point de vu jitter pour l'application, le full GC n'est pas pire qu'un minor GC, ca va juste occuper plus du CPU et pourrir temporairement tes caches CPU.
Par contre tu as quelques phases qui sont bloquantes, mais qui arrivent aussi en minor collection, et dont le temps d'exécution va dépendre de la tête de ta oldgen. Notament de sa fragmentation et de l'état des dirty cards. Ce qui fait que le full GC est rarement un problème, par contre tes performances se dégradent lentement jusqu'à ce qu'un full GC arrive.
Quand tu as ce genre de problèmes en général soit tu configures ton GC pour être aggressif et déclancher des full GC très tôt, soit tu forces des full GC reguliers via JMX. Les deux sont crados mais ca fait le job.
Je suis pas foncièrement en désaccord non plus. J'ai pas regarder rust en détail mais leur approche semble pas mal non plus.
Après je reste pragmatique par rapport aux outils actuellement disponibles et leur facilité d'utilisation/déploiement. Et surtout je n'oublie pas que je peux écrire du Java comme du C pour la gestion mémoire: je peux faire des alloc manuelle, je peux gérer mes alignements, je peux gérer ma contiguité etc.
La question qui se pose est donc:
- Quel est le meilleur outil pour écrire la majorité du code
- Puis-je atteindre les perfs visées pour le code qui a besoin d'être performant ? Exemple: Si j'ai besoin de SIMD Hotspot ne tient pas la route, mais je peux aussi sortir du C++ pour les 100 lignes de code qui en ont besoin ou tout faire en C++.
Maintenant si j'écrivais un jeu, je ne ferais clairement pas les mêmes choix que pour écrire du code backend.