Java a été créé en réaction à C++, tout objet, et une relation angoissée avec la gestion de la mémoire. Aucune gestion explicite de la mémoire ne doit être confiée au développeur, voilà, la règle est simple. La libération de la mémoire se fait avec le fameux garbage collector, mais ce n'est pas la seule tactique. Pour simplifier la gestion des pointeurs, Java souhaite travailler sans fragmentations, et donc réserve sa mémoire par avance. Il réserve, mais n'alloue pas, cela se fera au fur et à mesure. La mémoire qu'il se réserve est découpée en zone. On parle de vrai mémoire, le swap n'est pas une option envisageable pour Java, il est même possible de verrouiller sa part de mémoire pour ne garantir qu'il n'y aura pas de swap (avec mlockall).
Découpage
La zone mémoire est coupé une première fois en deux, la "heap" et le "permanent space". La heap est la zone de travail, l'autre partie est plus statique. La heap est séparée en deux parts : "young generation" et "survivor". Les objets sont d'abord instanciés en tant que "young generation", dans l'Eden, et s'ils survivent à deux ou trois garbage collector, ils deviennent des "survivors". Cette zone de mémoire subit moins fréquemment les passages du garbage collector, avec des tactiques tunées suite a de nombreux retours d'expérience, alors que dans l'Eden, l'approche est naïve. Le réglage classique est d'1/3 de jeune pour 2/3 de vieux. La seconde partie, le "Permanent space" contient le code, les buffers des sockets, les stacks des threads, le code JNI, et la gestion du "garbage collector". C'est l'arrière-cuisine, en fait, uniquement intéressant en cas de crash, en fait, comme lors de la création du thread natif de trop.
Tous ces réglages se font via des arguments dans la ligne de commande. Le tout étant emballé par les scripts de boot.
Les arguments principaux sont : Xmx , mémoire maximum, et Xms , mémoire minimal. Il est tout à fait possible de mettre la même valeur pour les deux.
JMX
