Quelle est la plus grande taille de tas possible avec une machine virtuelle Java 64 bits?
La valeur maximale théorique du tas qui peut être définie avec -Xmx dans un système 32 bits est bien sûr 2^32 octets, mais généralement (voir: Comprendre la taille maximale du segment de mémoire de la JVM - 32 bits contre 64 bits ), une capacité de 4 Go n'est pas utilisable.
Existe-t-il une limite autre que la limite théorique de 2^64 octets ou de 16 exaoctets pour une machine virtuelle Java 64 bits s'exécutant sur un système d'exploitation 64 bits sur un ordinateur 64 bits?
Je sais que pour diverses raisons (principalement la récupération de place), des tas trop volumineux pourraient ne pas être sages, mais à la lumière de la lecture sur les serveurs avec des terrabytes de RAM, je me demande ce qu'est possible.
Si vous souhaitez utiliser des références 32 bits, votre segment de mémoire est limité à 32 Go.
Toutefois, si vous souhaitez utiliser des références 64 bits, la taille sera probablement limitée par votre système d'exploitation, comme c'est le cas avec la JVM 32 bits. par exemple. sous Windows 32 bits, cela représente 1,2 à 1,5 Go.
Remarque: vous souhaiterez que votre segment de mémoire JVM s'insère dans la mémoire principale, idéalement dans une région NUMA. C'est à peu près 1 TB sur les plus grosses machines. Si votre machine virtuelle Java s'étend sur des régions NUMA, l'accès à la mémoire, et plus particulièrement le GC, prendra beaucoup plus de temps. Si votre segment de mémoire JVM commence à être échangé, le processus de conversion peut prendre des heures, voire devenir inutilisable, car il bloque le lecteur d'échange.
Remarque: vous pouvez accéder à de grandes tailles de mémoire directe et de mappage de mémoire même si vous utilisez des références 32 bits dans votre segment de mémoire. c'est-à-dire utiliser bien au-dessus de 32 Go.
Oops compressés dans la JVM Hotspot
Les oops compressés représentent les pointeurs gérés (à de nombreux endroits de la machine virtuelle Java mais pas à tous) en tant que valeurs 32 bits qui doivent être mises à l'échelle par un facteur 8 et ajoutées à une adresse de base 64 bits pour rechercher l'objet auquel elles font référence. Cela permet aux applications de traiter jusqu'à quatre milliards d'objets (pas d'octets), ou une taille de tas d'environ 32 Go. Dans le même temps, la compacité de la structure de données est compétitive par rapport au mode ILP32.
La réponse dépend clairement de la mise en œuvre de la machine virtuelle Java. Azul affirme que leur machine virtuelle
peut évoluer ... jusqu'à plus d'un demi-téraoctet de mémoire
Par "peut évoluer", ils semblent signifier "fonctionne bien" par opposition à "fonctionne du tout".
Windows impose une limite de mémoire par processus, vous pouvez voir ce que c'est pour chaque version ici
Voir:
User-mode virtual address space for each 64-bit process;With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default):x64: 8 TBIntel IPF: 7 TB2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared
J'ai essayé -Xmx32255M est accepté par vmargs pour les oops compressés.
Existe-t-il une limite autre que la limite théorique de 2 ^ 64 octets ou 16 exaoctets pour une machine virtuelle Java 64 bits exécutée sur un système d'exploitation 64 bits sur un ordinateur 64 bits?
Vous devez également prendre en compte les limites matérielles. Les pointeurs peuvent être des processeurs actuels de 64 bits ne peuvent s’adresser qu’à moins de 2 ^ 64 octets de mémoire virtuelle .
Avec des pointeurs non compressés, la machine virtuelle Java à point névralgique a besoin d'un bloc d'espace d'adressage virtuel continu pour son segment de mémoire. Le deuxième obstacle après le matériel est donc le système d’exploitation qui fournit un tel bloc, ce que tous les systèmes d’exploitation ne prennent pas en charge.
Et le troisième est l'aspect pratique. Même si vous pouvez disposer de beaucoup de mémoire virtuelle, cela ne signifie pas que les processeurs prennent en charge autant de mémoire physique, et sans mémoire physique, vous finirez par permuter, ce qui affectera les performances de la JVM, car les GC doivent généralement toucher une grande partie du tas.
Comme d'autres réponses mentionnent des oops compressés: en modifiant l'alignement de l'objet de plus de 8 octets, les limites avec oops compressés peuvent être augmentées au-delà de 32 Go