Maximum Java taille de segment de mémoire d'une JVM 32 bits sur un OS 64 bits

Question

La question n'est pas sur la taille maximale du tas sur un 32-bit OS, étant donné que 32 bits des Systèmes d'exploitation ont un maximum de mémoire adressable de 4 go, et que la JVM max taille de segment de mémoire dépend de la façon dont beaucoup contigu de mémoire libre peuvent être réservés.

Je suis plus intéressé à en savoir le maximum (à la fois théorique et pratiquement réalisable) taille de segment de mémoire pour une JVM 32 bits s'exécutant dans un OS 64 bits. En gros, je suis à la recherche des réponses similaires à les chiffres en question sur soi.

Pourquoi une JVM 32 bits est utilisé au lieu de 64-bit, la raison n'est pas technique, mais plutôt administrative et bureaucratique, il est probablement trop tard pour installer une JVM 64 bits dans l'environnement de production.

Answer 1

Vous pouvez demander à la Java Runtime:

public class MaxMemory {
    public static void main(String[] args) {
        Runtime rt = Runtime.getRuntime();
        long totalMem = rt.totalMemory();
        long maxMem = rt.maxMemory();
        long freeMem = rt.freeMemory();
        double megs = 1048576.0;

        System.out.println ("Total Memory: " + totalMem + " (" + (totalMem/megs) + " MiB)");
        System.out.println ("Max Memory:   " + maxMem + " (" + (maxMem/megs) + " MiB)");
        System.out.println ("Free Memory:  " + freeMem + " (" + (freeMem/megs) + " MiB)");
    }
}

Cela permettra de signaler le "Max de la Mémoire", sur la base par défaut de l'allocation de tas. Si vous avez encore besoin de jouer avec -Xmx (HotSpot). J'ai trouvé ce qui marche sur Windows 7 Entreprise 64 bits, mon 32 bits de la JVM HotSpot peut allouer jusqu'à 1577MiB:

[C:scratch]> java -Xmx1600M MaxMemory
Erreur s'est produite lors de l'initialisation de la VM
Ne pouvait pas réserver suffisamment d'espace pour des tas d'objets
N'a pas pu créer la machine virtuelle Java.
[C:scratch]> java -Xmx1590M MaxMemory
Mémoire Totale: 2031616 (1.9375 MiB)
Mémoire Max: 1654456320 (1577.8125 MiB)
Libérer De La Mémoire: 1840872 (1.75559234619 MiB)
[C:scratch]>

Alors qu'avec une JVM 64 bits sur le même OS, bien sûr, c'est beaucoup plus élevée (environ 3TiB)

[C:scratch]> java -Xmx3560G MaxMemory
Erreur s'est produite lors de l'initialisation de la VM
Ne pouvait pas réserver suffisamment d'espace pour des tas d'objets
[C:scratch]> java -Xmx3550G MaxMemory
Mémoire Totale: 94240768 (89.875 MiB)
Mémoire Max: 3388252028928 (3184151.84297 MiB)
Libérer De La Mémoire: 93747752 (89.4048233032 MiB)
[C:scratch]>

Comme d'autres l'ont déjà mentionné, il dépend de l'OS.

• Pour la version 32 bits de Windows: <2 go de ram (Windows internals livre dit de 2 go pour les processus utilisateur)
• Pour 32-bit BSD / Linux: <3 GO (à partir du Diable Livre)
• Pour 32-bit mac os X: <4 GO (à partir de Mac OS X entrailles livre)
• Ce n'est pas sûr 32 bits Solaris, essayez le code ci-dessus et laissez-nous savoir.

Pour une version 64 bits de l'OS hôte, si la JVM est en 32 bits, ça va encore dépendre, le plus probable, comme ci-dessus comme l'a démontré.

-- Mise à JOUR 20110905: je voulais Juste pointer un certain nombre d'autres observations / détails:

• Le matériel que j'ai couru ce sur est de 64 bits avec 6 go de réels RAM installée. Le système d'exploitation Windows 7 Entreprise 64 bits
• Le montant réel de l'Exécution.MaxMemory qui peut être alloué dépend aussi du système d'exploitation de l'ensemble de travail. J'ai relancé ce alors que j'avais aussi VirtualBox en cours d'exécution et trouvé que je pouvais pas réussir le démarrage de la JVM HotSpot avec -Xmx1590M et a dû aller plus petites. Cela implique également que vous pouvez obtenir plus de 1590M en fonction de votre taille du jeu de travail à l'époque (bien que j'avais encore maintenir ce sera sous 2GiB pour 32 bits, car de Windows " design)

Answer 2

32-bit les machines virtuelles qui s'attendent à avoir un seul grand morceau de la mémoire ne peut pas utiliser plus de 4 Go (puisque c'est le 32 bits limite qui s'applique également à des pointeurs). Cela comprend le Soleil et je suis assez sûr - aussi d'IBM mise en œuvre. Je ne sais pas si par exemple, JRockit ou d'autres ont une mémoire de grande capacité en option avec leurs 32 bits implémentations.

Si vous vous attendez à être atteint cette limite, vous devriez sérieusement envisager de commencer une voie parallèle de la validation d'une JVM 64 bits pour votre environnement de production, vous avez donc qu'prêt pour quand la version 32 bits de l'environnement se décompose. Sinon, vous devrez le faire travailler sous pression, ce qui n'est jamais agréable.

---

Edit 2014-05-15: Oracle FAQ:

Le montant maximum théorique de segment de limite pour la JVM 32 bits est la 4G. En raison de diverses contraintes supplémentaires telles que le swap disponible, l'espace d'adressage du noyau de l'utilisation, de la fragmentation de la mémoire et de traitement de l'ordinateur virtuel, dans la pratique, la limite peut être beaucoup plus faible. Sur les systèmes Windows 32 bits la taille maximale du tas sera de 1,4 G à 1,6 G. Sur 32 bits Solaris grains de l'espace d'adressage est limitée à la 2G. Sur 64 bits des systèmes d'exploitation 32 bits VM, le max de la taille du segment peut être plus élevé, à l'approche de la 4G sur de nombreux systèmes Solaris.

(http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit)

Answer 3

Vous ne spécifiez pas de qui OS.

Sous Windows (pour mon application une longue application de gestion des risques), nous avons observé que l'on pouvait aller plus loin que du 1280 MO sur Windows 32 bits. Je doute que la gestion d'une JVM 32 bits sous 64 bits ne fait aucune différence.

Nous avons porté à l'application de Linux et nous sommes en cours d'exécution d'une JVM 32 bits sur 64 bits du matériel et de 2,2 GO VM en cours d'exécution assez facilement.

Le plus grand problème que vous pouvez avoir est de GC en fonction de ce que vous êtes en utilisant de la mémoire.

Answer 4

À Partir 4.1.2 Tas De Dimensionnement:

"Pour un processus 32 bits de modèle, le maximum d'adressage virtuel de la taille de la le processus est généralement de 4 GO, bien que certains systèmes d'exploitation limiter à la 2 GO ou 3 GO. La taille maximale du tas est généralement -Xmx3800m (1600m) pour 2 GO de limites), mais la limitation dépend de l'application. Pour 64-bit, modèles de processus, le maximum est essentiellement illimitée".

Trouvé une assez bonne réponse ici: Java maximale de la mémoire sous Windows XP.

Answer 5

Nous avons récemment eu une certaine expérience avec ce. Nous avons porté à partir de Solaris (x86-64 Version 5.10) pour Linux (RedHat x86-64) récemment et avons réalisé que nous avons moins de mémoire disponible pour un 32 bits, processus de JVM sur Linux que sous Solaris.

Pour Solaris ce presque est à 4 GO (http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit).

Nous avons couru notre app avec -Xms2560m -Xmx2560m -XX:MaxPermSize=512m -XX:PermSize=512m avec pas de questions sur Solaris pour les deux dernières années. Tenté de passer à linux et nous avons eu des problèmes avec aléatoire des erreurs de mémoire insuffisante sur démarrer. Nous ne pouvions obtenir de toujours démarrer sur -Xms2300 -Xmx2300. Ensuite, nous avons été informés de ce soutien.

Un processus 32 bits sous Linux a un maximum adressable de l'espace d'adresse de 3 go (3072) alors que sur Solaris, il est la totale de 4 go (4096 mo).