Allez, juste pour le plaisir du troll et parce que c'est Lundi. Une petite dédicace venant de la FAQ de cassandra:
"In most cases, the capability of Java to gracefully handle garbage collection above 8GB quickly diminishes."
Puisque l'on parle de JVM et de gc, c'est curieux que ton lien ne parle pas également du "compressed Oops trick".
C'est un petit peu hors-sujet par rapport à la dépêche mais comme je trouve cela intéressant, je partage quand même. Pour résumer, il est en général déconseillé d'allouer plus de 32G à la JVM sous peine de souffrir d'une baisse drastique de performance (régression avec une heap de 50G par rapport à une heap de 30G par exemple).
Cela est dû au fait que la JVM utilise un trick: les pointeurs de référence ("Ordinary object pointers") sont de 32-bit jusqu'à cette "limite" de 32G. Comme ces pointeurs réfèrent des objets alignés à l'octet, ils référencent des offsets plutôt que des octets directement. Cela permet donc de référencer ~4mia d'objets plutôt que de byte. On arrive donc à référencer près de 32G au lieu de 4G avec des pointeurs de 32-bit. En revanche, passé cette limite, les pointeurs passent à une taille de 64-bit au lieu de 32-bit afin de pouvoir référencer l'entier de la heap allouée à la JVM. Comme la taille des pointeurs double, plus de ressources CPU/mémoire sont sollicitées d'où une régression de performance et dans les fait, on "perd" de la mémoire effective. Bien entendu, passé une certaine taille d'allocation de mémoire à la JVM, on les "récupère".
[^] # Re: Destructeurs
Posté par Rolinh . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 6.
Puisque l'on parle de JVM et de gc, c'est curieux que ton lien ne parle pas également du "compressed Oops trick".
C'est un petit peu hors-sujet par rapport à la dépêche mais comme je trouve cela intéressant, je partage quand même. Pour résumer, il est en général déconseillé d'allouer plus de 32G à la JVM sous peine de souffrir d'une baisse drastique de performance (régression avec une heap de 50G par rapport à une heap de 30G par exemple).
Cela est dû au fait que la JVM utilise un trick: les pointeurs de référence ("Ordinary object pointers") sont de 32-bit jusqu'à cette "limite" de 32G. Comme ces pointeurs réfèrent des objets alignés à l'octet, ils référencent des offsets plutôt que des octets directement. Cela permet donc de référencer ~4mia d'objets plutôt que de byte. On arrive donc à référencer près de 32G au lieu de 4G avec des pointeurs de 32-bit. En revanche, passé cette limite, les pointeurs passent à une taille de 64-bit au lieu de 32-bit afin de pouvoir référencer l'entier de la heap allouée à la JVM. Comme la taille des pointeurs double, plus de ressources CPU/mémoire sont sollicitées d'où une régression de performance et dans les fait, on "perd" de la mémoire effective. Bien entendu, passé une certaine taille d'allocation de mémoire à la JVM, on les "récupère".