Java 32 bits Xmx vs java 64 bits Xmx

Il y a une distinction entre l'attribution de la mémoire et de l'allocation de l'espace d'adressage. L'Oracle de la JVM est de l'allocation de la espace d'adressage au démarrage pour assurer le tas est contiguë. Cela permet pour certaines optimisations pour être utilisé avec le tas.

Si l'allocation échoue, alors Java ne démarre pas... comme vous l'avez vu. Il n'est pas nécessairement en utilisant beaucoup de mémoire, mais c'est l'attribution de l'adresse requise de l'espace à l'avant. Puisque vous êtes de passage à -Xmx1536m, il est dit ok, j'ai besoin d'allouer que dans le cas où vous en avez besoin... et depuis il doit être contiguës, il n'a à l'avant de sorte qu'il peut garantir qu'il (ou ne parvient pas à essayer).

Ce comportement est le même sur les deux versions 32 bits et 64 bits Jvm. Ce que vous voyez est les 2 go par espace d'adressage du processus de limitation des processus 32 bits (au moins, sur Windows c'est de la limitation - c'est peut-être légèrement plus grand que sur les autres plateformes), la cause de cette allocation échoue sur 32 bits, où 64 bits n'a pas de problèmes car il a beaucoup plus d'espace d'adresse. Mais, dites-vous, 1536m est à moins de 2 GO, je devrais être bon, non? Pas tout à fait - le tas n'est pas la seule chose qui est alloué dans l'espace d'adressage, les Dll et d'autres choses est également attribuée dans l'espace d'adressage...afin d'obtenir un contiguë 1536m morceau de 2 GO max sur 32 bits est malheureusement très rare. J'ai vu des valeurs en dessous de 1000m d'échouer sur les processus 32 bits particulièrement mauvaise fragmentation, et généralement 1200-1300m est le max de tas vous pouvez spécifier sur 32 bits.

Sur de nouveaux Systèmes d'exploitation, ASLR (Address Space Layout Randomization) fait de la fragmentation des processus 32 bits de l'adresse de l'espace pour le pire. Il intentionnellement chargement des Dll en aléatoire des adresses pour des raisons de sécurité... ce qui rend encore moins probable que vous pouvez obtenir un grand, contiguë tas en 32 bits.

En 64 bits, l'adresse de l'espace est tellement grand que la fragmentation n'est plus un problème et le géant des tas peuvent être attribuées sans problèmes. Même si vous avez 4 go de RAM en 32 bits, bien que, les 2GO par processus de l'adresse de limitation d'espace (au moins sous Windows) signifie en général que le max de tas est généralement 1300m.

OriginalL'auteur Joshua McKinnon

Sous Windows il y a une différence dans l'allocation de la mémoire des opérations natif de la WinAPI fonctions de bas niveau comme VirtualAlloc.

"Réservataire" signifie l'allocation d'une zone continue, au sein d'espace d'adressage du processus, sans faire réellement de cette zone de mémoire virtuelle utilisable. Zone allouée n'est pas soutenu par la physique réelle de la RAM ou d'espace de swap et de ne pas consommer toute la mémoire libre. Toutes les applications peuvent réserve de toute quantité d'espace d'adressage limité que par la mémoire du processeur de l'adressage de la capacité (nombre de bits).

"S'engager" signifie la sauvegarde de certains de déjà "réservés" de la mémoire avec le réel de la mémoire RAM ou d'espace de swap, le rendant réellement accessible en lecture/écriture par le processus. Cette mémoire est prise à partir de la disposition de l'OS virtual pool de mémoire vive (RAM et swap).

Une alternative à "s'engager" de la mémoire (en prenant une page vierge de la piscine) est "mapping" d'un fichier dans le déjà "réservés" de la mémoire. Ce ne consomme pas de mémoire de l'échange de la piscine, mais utilise le fichier mappé dans une manière similaire à l'espace de swap pour cette région d'un espace d'adressage du processus.

Natif des applications de Windows (comme la JVM elle-même) réserver de la mémoire pour tous les segments de mémoire nécessaire à l'avenir, mais n'engagent uniquement quand c'est nécessaire.
De haut niveau, les opérations de mémoire comme malloc() des fonctions de style ou de "nouveaux" opérateurs vraiment "s'engage" en tant que de besoin, ou même faire leurs propres tas de gestion de la logique de l'utilisateur-mode mémoire commis à l'avance par les gros morceaux comme il est un PROCESSEUR de noyau d'appel et travaille à la page (4k) de granularité.

Au cours du processus de démarrage de la JVM "réserves" -Xmx mémoire, mais "s'engage" seulement -Xms. Le reste réservée de la mémoire s'est engagé à la demande des tas de croître. Donc, des tas de grandir à la mémoire disponible ou -Xmx paramètre, selon le moindre des deux.

OriginalL'auteur Сергей Морсин