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())
Donc, tu ne peux pas dire "il me reste 14ms pour cette frame-ci, gc pendant ce temps" et à la frame suivante lui demander de le faire pendant 5ms parce que tu as du faire du calcul un peu plus intensif.
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é
Mais rien de tout ça n'est dynamique vu ce que tu as écrit plus haut.
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.
C'est bien beau, mais quand ça dépend de l'utilisateur on est loin d'un truc qui scale automagiquement
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.
On est d'accord que l'utilisation d'une VM avec ses propres types te permet plus de possibilité au niveau de l'auscultation de ta mémoire. Mais si tu te retrouves dans le cas ci-dessus avec les garbage collector actuels, t'as rien d'autre à faire que tortiller tes données et virer des features pour pouvoir éviter d'avoir à nettoyer quand une gestion manuelle aurait pu t'éviter ce soucis.
Je ne dis pas qu'il n'est pas possible d'avoir un GC qui fonctionne sur ce principe, mais visiblement ça court pas les rues..
Merci de prendre le commentaire ci-dessus avec: un peu de recul, le premier degré, et si possible le second !
[^] # Re: Ne pas craindre la Faucheuse
Posté par Elfir3 . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été. Évalué à 3.
Donc, tu ne peux pas dire "il me reste 14ms pour cette frame-ci, gc pendant ce temps" et à la frame suivante lui demander de le faire pendant 5ms parce que tu as du faire du calcul un peu plus intensif.
Mais rien de tout ça n'est dynamique vu ce que tu as écrit plus haut.
C'est bien beau, mais quand ça dépend de l'utilisateur on est loin d'un truc qui scale automagiquement
On est d'accord que l'utilisation d'une VM avec ses propres types te permet plus de possibilité au niveau de l'auscultation de ta mémoire. Mais si tu te retrouves dans le cas ci-dessus avec les garbage collector actuels, t'as rien d'autre à faire que tortiller tes données et virer des features pour pouvoir éviter d'avoir à nettoyer quand une gestion manuelle aurait pu t'éviter ce soucis.
Je ne dis pas qu'il n'est pas possible d'avoir un GC qui fonctionne sur ce principe, mais visiblement ça court pas les rues..
Merci de prendre le commentaire ci-dessus avec: un peu de recul, le premier degré, et si possible le second !