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

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.

InformationsquelleAutor Vineet Reynolds | 2009-09-16
  1. 65

    32 bits Jvm qui s'attendent à avoir un seul grand morceau de la mémoire et utiliser des pointeurs 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.

    Modifier 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, espace d'adressage du noyau de l'utilisation, de 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)

    • Pas de pression au travail ici. Je sais qu'une JVM 64 bits doit avoir été installé à la première place. Mais il m'a fait penser à la façon dont une JVM 32 bits serait de travailler dans un environnement avec plus de ressources à sa disposition.
    • N'est-il pas autour de 2 GO parce que de la signednes? Ou est-ce juste la JVM de Sun?
    • Les pointeurs ne sont pas signés, il ne fait pas de sens de parler de négatif emplacements de mémoire.
    • Non, il n'est pas de 2 go à cause de ce paramètre. Toutefois, une partie de l'adressage de 4 go espace est réservé pour le noyau de système d'exploitation. Normal, les versions grand public de Windows, la limite est de 2 go. Sur Linux et les versions serveur de Windows (32 bits), la limite est de 3 go par processus.
    • de plus, cette plate-forme est dépendante. C'est le PC-architecture imposante de cette limite.
    • Je me demandais si une JVM 32 bits s'exécutant sur un système d'exploitation 64 bits pourrait avoir un complet de 4 GO d'espace d'adressage disponible?
    • Serait-il possible pour une JVM pour utiliser une version 32 bits de type d'objet, mais de préciser que ces 32 bits contenir une valeur qui est de 1/8 de la "vraie" adresse, de sorte que le chargement d'un mot à partir de 28 décalage d'un lieu de référence dans EBX serait mov eax,[ebx*8+28]? Pour les projets qui avaient besoin entre 4 GO et ~32 GO de mémoire, qui semble plus efficace que d'utiliser encombrants 64 bits références.
    • jetez un oeil à blogs.oracle.com/jrockit/entry/understanding_compressed_refer
    • Cool. J'ai longtemps pensé que l'Intel 8086 schéma d'adressage a été injustement décrié. Un mode où les registres de segment ont simplement changé de 4 places et ajouté à un décalage serait idéal pour un framework orienté objet; il pourrait être encore mieux si la partie supérieure du registre de segment a été utilisé pour sélectionner parmi configurable en abordant les domaines, avec différents facteurs d'échelle. Avoir une partie de la mémoire pour les objets de petite taille, avec un facteur d'échelle de 8, et un autre pour les moyennes et les objets avec un facteur d'échelle de 64, et un pour les grands objets avec un facteur d'échelle de 256.
    • vous avez besoin de prendre de collecte des ordures en considération. Ce que vous suggérez signifie essentiellement que vous introduire plusieurs nouveaux séparer les zones de mémoire où les objets ne peuvent pas migrer facilement de l'un à l'autre, rendant la collecte des ordures beaucoup plus complexe.
    • Il y aurait des zones séparées tas optimisé pour les différentes tailles d'objets, mais je ne vois pas d'obstacle à déplacer les objets entre eux. On pourrait avoir plus d'espace en gros-grain zones de petit-grain, de sorte que l'on préférerait mettre des objets qui ne bénéficieraient pas de petits grains dans les domaines plus gros-grain lorsque pratique; de plus, la perte d'un moyen par exemple de 128 octets par répartition dans le gros grain de la zone serait de dire qu'on doit préférer à éviter de l'utiliser pour des objets où cette perte serait importante, mais...
    • ...ne devrait avoir aucune objection à utiliser pour les objets qui sont par exemple en 4K ou de plus grande taille.
    • Je vous suggère de regarder dans les différents documents de recherche sur la collecte des ordures où j'en suis certain, votre suggestion a été pensé et analysé. Ma conjecture est que le concierge de travail nécessaire, il est moins intéressant que les autres approches.
    • J'ai trouvé le plus de Windows 7 32 bits jre dans mon entreprise ne peut pas utiliser de 1,4 G de mémoire. Il suffit donc de ne pas s'appuyer sur ce que l'Oracle a dit que si vous souhaitez utiliser plus de mémoire que possible.
    • vous avez besoin de suffisamment de RAM pour soutenir donnant la JVM de la mémoire supplémentaire (c'est à dire assez de swap).
    • Dans mon windows7 64 bits avec 64 bits jre. Peut -Xmx600G, mais j'ai seulement 16 go de mémoire RAM installée sur mon PC.

    InformationsquelleAutor Thorbjørn Ravn Andersen
  2. 85

    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 (sur HotSpot). J'ai trouvé ce qui marche sur Windows 7 Entreprise 64 bits, mon 32 bits 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 un 64 bits de la JVM 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 Windows 32 bits: il sera <2 GO (Windows internals livre dit 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 internals livre)
    • Pas sûr de 32 bits Solaris, essayez le code ci-dessus et laissez-nous savoir.

    Pour un 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 souligner un certain nombre d'autres observations /détails:

    • Le matériel que j'ai couru ce sur de 64 bits avec 6 go de réels RAM installée. Le système d'exploitation est Windows 7 Entreprise 64 bits
    • Le montant réel de la Runtime.MaxMemory qui peut être alloué dépend aussi du système d'exploitation jeu de travail. Une fois, j'ai couru 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 (même si je maintiens ce sera sous 2GiB pour 32 bits, car de Windows " design)
    • J'aime que vous avez réellement mis à l'épreuve plutôt que de conjectures.
    • Difficile de croire qu'un 32 bits de la JVM hotspot dit qu'il a 15 GO de libre. Je ne le crois pas. Il ne fait aucun sens.
    • est droit. Le programme devrait être en divisant par 1 048 576 octets (1024*1024, ou 2^20), pas 104,856. Mais, c'est juste un affichage de la chose. Comme vous pouvez le voir à partir de la commande, il a seulement essayé de définir la taille maximale du tas de 1590 à MiB.
    • Ahhh ouais. Je vois maintenant.
    • Oups, oui, erreur de transcription de ma calculatrice: 1024*1024 = 1048576. Désolé j'ai raté le 7 🙂 je vais modifier ci-dessus et de ré-exécuter...
    • Très cool réponse (je tiens à dire le réponse), avec un exemple de code, et les détails couvrant tous les Systèmes d'exploitation.
    • Suite à mon commentaire précédent: Le jdocs (pour windows atleast) précisent que l'-Xmx et -Xms paramétrée doit être donné une valeur qui est un multiple de 1024... je ne sais pas si 1590 est, donc je pense que d'étranges résultats devrait être prévu.
    • Bien repéré TGP1994. Je pense que, parce que j'ai précisé " M " et " G " multiples, puis la taille (en octets) va travailler à être un multiple de 1024 octets, de toute façon. par exemple, 1590M sera analysée à 1590*(1024*1024) = 1667235840 octets (1628160KiB -- un multiple de 1024 bien sûr).
    • Pour moi, il semble massivement varient sans doute en fonction de la précision de la mémoire de partitionnement de l'exécution des applications (c'est à dire, l'ensemble de travail). J'ai situations avec 4,5 GO de RAM gratuit (sur Win 10 x64) et pourtant je ne peut allouer 1012MB ou 1024MB de la mémoire. Il n'y a pas d'informations plus détaillées/explication de ce à partir d'Oracle ou similaires?
    • Dans mon blog à partir de 2007 (il y a 9 ans!) J'ai ajouté une mise à jour, avec quelques très bonnes infos à partir de ce DONC, la question et cet excellent article du blog par Dhamvir Singh. Vous recommande la lecture de son post pour plus de détails.
    • Vous devriez être en mesure de faire 2^64 bits de répartition, même si la RAM est dépassé dans la JVM x 64.
    • eh bien, non, pas vraiment. La plupart des 64 bits des Systèmes d'exploitation ne permettent pas de 18 exabyte (16 exbibyte) les allocations de même dans la mémoire virtuelle, même si elles avaient le swap de soutien. Il n'est pas pratique à partir d'un OS point de la conception-même les supercalculateurs sont limitées à des centaines de giga-octets de RAM et des dizaines, voire des centaines, de pétaoctets de stockage en ligne! L'adresse de l'espace est mieux utilisé à d'autres fins. De toute façon le programme dans ma réponse montre la différence entre la théorie et la pratique....

    InformationsquelleAutor mike
  3. 16

    Vous ne spécifiez pas 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 pour 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 pour les.

    • Je préfère, à savoir la limitation de Solaris 10, mais c'est uniquement pour mon problème à portée de main. Voudrais savoir pour les autres Systèmes d'exploitation ainsi, pour un jour de pluie 🙂
    • Pas sûr au sujet de Solaris. J'attendrais la taille de mémoire virtuelle à être assez grand, mon expérience de Java sur Solaris était il y a quelques années. Et d'être un Soleil VM sur un Sun OS sur le Soleil matériel choses assez bien travaillé. J'ai également été amené à croire qu'il y avait moins de GC questions sous Solaris que sur Linux/Windows.
    • Qui Windows ce. Je crois que les versions serveur de Windows 32 bits peut gérer de grandes quantités de mémoire de beaucoup mieux.
    • Ah, enfin une mention de l'OS 😉 Vous avez un noyau 64 bits installé?
    • Il a été Win2k server. Un déménagement à Win2k3 (les choses bougent lentement..) était trop tard et nous nous sommes mis à Linux à la place.
    • Upvoted pour votre mention de la GC question - très important pour les grandes VM tailles.
    • Grande réponse avec quelques miettes de yummy info...

    InformationsquelleAutor Fortyrunner
  4. 14

    De 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 quasiment illimitées."

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

    InformationsquelleAutor djangofan
  5. 12

    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 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.

    D'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).

    • La raison de la réponse donnée par le support réside dans la façon dont beaucoup de mémoire adressable est disponible pour un processus. Cela dépend du noyau Linux et même sur le matériel. Théoriquement, la mémoire adressable est limité à 2^32 = 4G (et la Java de la taille du segment serait moindre que cela). Mais, cela peut (théoriquement) être étendu à l'aide d'hugemem et PAE; je n'ai pas tenté cette.
    InformationsquelleAutor chinto
  6. 9

    Les limites d'une JVM 32 bits sur un OS 64 bits sera exactement le même que les limites d'une JVM 32 bits sur un 32-bit OS. Après tout, la JVM 32 bits En 32 bits et la machine virtuelle (dans le sens de virtualisation) de sorte qu'il ne sait pas qu'il est en cours d'exécution sur un système d'exploitation 64 bits/ordinateur.

    Un avantage à l'exécution d'une JVM 32 bits sur un OS 64 bits contre 32-bit OS que vous pouvez avoir plus de mémoire physique, et par conséquent à la rencontre d'échange/de pagination moins fréquemment. Cet avantage n'est pleinement réalisée que lorsque vous avez plusieurs processus, cependant.

    • Il peut y avoir une légère différence selon le matériel et la façon dont il est virtualisé. Certains de de la de 4 go espace adressable est généralement utilisé pour les périphériques mappés en mémoire. La couche de virtualisation peut ou peut ne pas avoir le même espace de mémoire physique de la machine.
    • Pas tout à fait. Il n'y a plus de place pour la JVM dans une machine 64 bits depuis l'espace d'adressage 32 bits n'a pas à être partagé avec le système d'exploitation ou des interfaces matérielles.
    • C'est vrai, mais tout cela signifie, c'est que votre 32-bit-machine virtuelle peut avoir de légères différences dans les frais généraux de 32 bits-réelle-de la machine (que ce soit pour le pire, ou le meilleur). De toute façon, vous êtes en cours d'exécution de la JVM sur un 32 bits-machine (réel ou virtuel) et ainsi vous serez soumis à la norme 32 bits contraintes. c'est à dire: un plafond absolu de 4 GO.
    • Thorbjørn: le système d'exploitation et des interfaces matérielles doivent encore être mappé dans la version 32 bits de VM. Le montant précis de entendu peut être différent, mais il va toujours être là. Si vous pouvez virtualiser sous un OS 64 bits qu'est-ce qui vous empêche de virtualisation sous un 32-bit OS? C'est virtual de la mémoire dont nous parlons.
    • LG: je suis en désaccord avec l'original de votre réponse. Le noyau de système d'exploitation et tout le MATÉRIEL de bus et de l'espace d'adresse il cartes mâchent beaucoup de l'espace d'adressage, et si ce n'est pas mappé dans le programme utilisateur, il n'réduire la quantité "à gauche sur" après l'OS a mis d'elle-même. C'est une quantité considérable de 4 go espace de 32 bits. Traditionnellement, cela signifie qu'environ 25%-75% de la 4 GO n'est pas disponible pour les processus utilisateur. 🙂 kernel hacker
    • Eric, Thorbjørn +1. C'est précisément pourquoi un 32-bit OS ne peut pas utiliser tous les 4 go de RAM disponible.
    • LG: en ce qui concerne votre commentaire. Certes, il est théoriquement possible que le noyau de système d'exploitation et les processus utilisateur d'être dans des espaces virtuels, et cela a été vrai depuis l'origine i386. Cependant, ce n'est pas comment les OS, les noyaux sont écrites, parce qu'il est si difficile de passer les données à partir du noyau. Il est intéressant de noter que certains systèmes 16 bits, en vertu de graves espace d'adressage de la pression, en fait pourrait le faire. Je suis sûr qu'il y a quelque obscure 32 bits, aussi, mais autant que je sache, il est extrêmement rare.
    • Laurence Gonsalves, je vous encourage à regarder la quantité de mémoire peut être faite directement à la disposition d'un processus 32 bits sous un moderne système d'exploitation 64 bits.

    InformationsquelleAutor Laurence Gonsalves
  7. 6

    Pourquoi une JVM 32 bits est utilisé au lieu de 64-bit, la raison n'est pas technique, mais plutôt administrative et bureaucratique ...

    Lorsque je travaillais pour le BEA, nous avons constaté que la moyenne de la demande en fait couru plus lent dans une JVM 64 bits, alors il l'a fait lors de l'exécution dans une JVM 32 bits. Dans certains cas, l'impact sur les performances a été aussi élevé que 25% plus lente. Donc, sauf si votre application a vraiment besoin de tout ce que la mémoire supplémentaire, vous avez été mieux de mettre en place plusieurs serveurs 32 bits.

    Que je me souviens, les trois communes les plus techniques, les justifications à l'aide d'un 64 bits que BEA professionnelle du personnel des services couru en étaient:

    1. La demande était de la manipulation de plusieurs massive des images,
    2. Faisait l'application massive de nombreux calculs,
    3. L'application avait une fuite de mémoire, le client a été le premier sur un
      contrat avec le gouvernement, et ils ne veulent pas prendre le temps et la
      frais de retracer la fuite de mémoire. (À l'aide d'un massif de mémoire
      tas pourrait augmenter le MTBF et le premier serait toujours payé)

    .

    • C'est gentil de vous fournir des conseils de première main, BEA, l'ex-travailleur 🙂
    InformationsquelleAutor user1564349
  8. 4

    La JROCKIT JVM actuellement détenue par Oracle prend en charge les non-contiguë de l'utilisation du tas, permettant ainsi à la JVM 32 bits pour accéder à plus de 3,8 GO de mémoire lorsque la JVM est en cours d'exécution sur une version 64 bits de windows OS. (2,8 GO lors de l'exécution sur un OS 32 bits).

    http://blogs.oracle.com/jrockit/entry/how_to_get_almost_3_gb_heap_on_windows

    La JVM peut être téléchargé gratuitement (inscription obligatoire) à

    http://www.oracle.com/technetwork/middleware/jrockit/downloads/index.html

    InformationsquelleAutor Dale
  9. 4

    Voici quelques tests sous Solaris et Linux 64 bits

    Solaris 10 - SPARC - T5220 machine avec 32 GO de RAM (et environ 9 GO de libre)

    $ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3750m MaxMemory
Error occurred during initialization of VM
Could not reserve space for ObjectStartArray
$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3700m MaxMemory
Total Memory: 518520832 (494.5 MiB)
Max Memory:   3451912192 (3292.0 MiB)
Free Memory:  515815488 (491.91998291015625 MiB)
Current PID is: 28274
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Server VM (build 20.5-b03, mixed mode)

$ which java
/usr/bin/java
$ file /usr/bin/java
/usr/bin/java: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped, no debugging information available

$ prstat -p 28274
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
28274 user1     670M   32M sleep   59    0   0:00:00 0.0% java/35

    BTW: Apparemment, Java ne pas allouer beaucoup de mémoire réelle avec le démarrage. Il semblait prendre à seulement 100 MO par exemple commencé (j'ai commencé à 10)

    Solaris 10 x86 - VMWare VM avec 8 GO de RAM (3 GO d'espace libre*)

    Les 3 GO de mémoire vive n'est pas vraiment vrai. Il y a une grande partie de la RAM que ZFS caches utiliser, mais je n'ai pas accès à la racine de vérifier combien exactement

    $ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3650m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3600m MaxMemory
Total Memory: 516423680 (492.5 MiB)
Max Memory:   3355443200 (3200.0 MiB)
Free Memory:  513718336 (489.91998291015625 MiB)
Current PID is: 26841
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_41"
Java(TM) SE Runtime Environment (build 1.6.0_41-b02)
Java HotSpot(TM) Server VM (build 20.14-b01, mixed mode)

$ which java
/usr/bin/java

$ file /usr/bin/java
/usr/bin/java:  ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available

$ prstat -p 26841
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
26841 user1     665M   22M sleep   59    0   0:00:00 0.0% java/12

    RedHat 5.5 - x86 - VMWare VM avec 4 GO de RAM (environ 3,8 GO utilisés - 200 MO dans les tampons et 3.1 GO dans les caches, donc environ 3 GO libre)

    $ alias java='$HOME/jre/jre1.6.0_34/bin/java'
$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3500m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3450m MaxMemory
Total Memory: 514523136 (490.6875 MiB)
Max Memory:   3215654912 (3066.6875 MiB)
Free Memory:  511838768 (488.1274871826172 MiB)
Current PID is: 21879
Waiting for user to press Enter to finish ...
$ java -version
java version "1.6.0_34"
Java(TM) SE Runtime Environment (build 1.6.0_34-b04)
Java HotSpot(TM) Server VM (build 20.9-b04, mixed mode)
$ file $HOME/jre/jre1.6.0_34/bin/java
/home/user1/jre/jre1.6.0_34/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped
$ cat /proc/21879/status | grep ^Vm
VmPeak:  3882796 kB
VmSize:  3882796 kB
VmLck:         0 kB
VmHWM:     12520 kB
VmRSS:     12520 kB
VmData:  3867424 kB
VmStk:        88 kB
VmExe:        40 kB
VmLib:     14804 kB
VmPTE:        96 kB

    Même machine à l'aide de JRE 7

    $ alias java='$HOME/jre/jre1.7.0_21/bin/java'
$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3500m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3450m MaxMemory
Total Memory: 514523136 (490.6875 MiB)
Max Memory:   3215654912 (3066.6875 MiB)
Free Memory:  511838672 (488.1273956298828 MiB)
Current PID is: 23026
Waiting for user to press Enter to finish ...
$ java -version
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) Server VM (build 23.21-b01, mixed mode)
$ file $HOME/jre/jre1.7.0_21/bin/java
/home/user1/jre/jre1.7.0_21/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
$ cat /proc/23026/status | grep ^Vm
VmPeak:  4040288 kB
VmSize:  4040288 kB
VmLck:         0 kB
VmHWM:     13468 kB
VmRSS:     13468 kB
VmData:  4024800 kB
VmStk:        88 kB
VmExe:         4 kB
VmLib:     10044 kB
VmPTE:       112 kB
    • Il y a quelques résultats de test ici pour les plates-formes que nous avons été absent. Bon travail avec l'utilisation de fichier et les vidages de mémoire aussi.
    InformationsquelleAutor ih.ng
  10. 3

    Devrait être beaucoup mieux

    Pour une JVM 32 bits s'exécutant sur un hôte 64 bits, j'imagine ce qu'il en reste pour le tas sera quel que soit fragmenté, l'espace virtuel est disponible après la JVM, c'est propre DLL, et tout système d'exploitation 32 bits trucs compatibilité a été chargé. Comme un sauvage suppose que je pense que 3 GO devrait être possible, mais comment beaucoup mieux dépend de la façon dont vous faites en 32 bits-accueil-land.

    Aussi, même si vous pouvez faire un géant de 3 GO de tas, vous pourriez ne pas vouloir, ce qui causera la GC s'arrête pour devenir potentiellement gênants. Certaines personnes juste courir plus de la JVM de l'utilisation de la mémoire supplémentaire plutôt qu'un géant. J'imagine qu'ils sont à un réglage de la JVM est en ce moment à mieux travailler avec les géants des tas.

    C'est un peu dur de savoir exactement comment beaucoup mieux que vous pouvez faire. Je suppose que votre 32-bit situation peut être facilement déterminée par l'expérience. Il est certainement difficile de prédire de façon abstraite, comme beaucoup de choses facteur, en particulier parce que l'espace virtuel disponible sur 32 bits hôtes est limitée.. Le tas ne doivent exister dans contigu de mémoire virtuelle, de sorte que la fragmentation de l'espace d'adressage pour les dll et l'utilisation interne de l'espace d'adressage par le noyau du système d'exploitation permettra de déterminer l'éventail des possibilités d'affectations.

    Système d'exploitation à l'aide de certains de l'espace d'adressage pour la cartographie HW dispositifs et il est propre allocations dynamiques. Tandis que cette mémoire n'est pas mappé dans la java espace d'adressage du processus, le noyau de système d'exploitation ne peut pas accéder à votre espace d'adressage dans le même temps, de sorte qu'il sera de limiter la taille de n'importe quel programme de l'espace virtuel.

    Chargement de la DLL dépend de la mise en œuvre et de la libération de la JVM. Le chargement du noyau de système d'exploitation dépend d'un grand nombre de choses, la libération, la HW, combien de choses il a mappé depuis le dernier redémarrage, qui sait...

    En résumé

    Je parie que vous obtenez de 1 à 2 GO en 32 bits-terre, et sur 3 en 64 bits, donc une amélioration globale d'environ 2x.

    • Malheureusement, je n'ai pas un environnement 64 bits à ma disposition où j'ai pu expérimenter avec la Xmx drapeau. Le seul que je connais est un gigantesque (32 * n)GO quantité de RAM disponible, mais en dehors des limites. C'est pourquoi je voulais savoir comment une JVM 32 bits serait de travailler sans toutes les contraintes normalement visages dans une version 32 bits de monde.
    • Eh bien, bonne question. Je suis sûr que la base, la réponse est "cela fonctionne mieux".
    • Ok, j'ai édité ma réponse à concentrer un peu plus sur votre question. 🙂
    • ≅ 3 GO en 64 bits sonne juste sur la droite. Thorbjørn avait déjà indiqué pourquoi il ne peut théoriquement dépasser 4 GO. Dommage que je ne peut pas accepter deux réponses.
    • Pas de problème, vous pouvez upvote tous les deux. 🙂
    • Si vous avez un grand boîte, vous pouvez expérimenter avec une version 64 bits de Solaris par exemple virtualbox (qui a le meilleur Solaris des invités).
    • 64 bits prend en charge de manière plus que la 3G. 1000G est pas un problème. Upvoting est certainement le mal de ce à faire en réponse à ce SUPPOSE que stackoverflow.com/questions/2093679/max-memory-for-64bit-java
    • la question il dit que c'est une version 32 bits de Java pour des raisons politiques. Donc, il est limité à 4 GO pour la somme totale de Java + bibliothèques + interprète + toutes les autres sources de frais généraux. Mon point est que la limite, il sera frappé sera quelque peu différente, s'il est sur un 64 bits kernel vs 32 bits kernel.
    • Vous l'avez dit vous-même votre réponse est sauvage suppose que. Dernière, j'ai vérifié, les devinettes au lieu de test est toujours une mauvaise idée. L'exécution d'une jvm 32 bits sur un windows 64 bits machine n'aidera PAS beaucoup, parce que vous avez besoin de l'OS, de façon à allouer de la mémoire contiguë, et les Dll chargées par le système qui vous limite à 1,5-1,8 G, indépendamment de l'arch. Si vous avez un système 64 bits avec beaucoup de mémoire, la jvm peut être en mesure de trouver beaucoup de inutilisés de mémoire contiguë, mais vous ne serez pas comme par magie obtenez 2X les avantages parce que l'OS est en 64 bits. stackoverflow.com/questions/171205/...
    • Si vous testez votre hypothèse et un lien vers la preuve, je serais plus qu'heureux de vous excuser. Jusqu'alors, cependant, le fardeau de la preuve incombe à la personne qui fait la demande.

    InformationsquelleAutor DigitalRoss
  11. 2

    Sur Solaris, la limite a été d'environ 3,5 GO depuis Solaris 2.5. (environ 10 ans)

    • Je vais tenter l'expérience, à l'aide d'Oracle Solaris Express 11.
    • Lawrey Uhm.. Solaris 2.5 a près de 20 ans si l'on considère la date de sortie de Mai 1996.... bien sûr, il n'a pas de fin de ligne jusqu'à autour de 2005.
    InformationsquelleAutor Peter Lawrey
  12. 1

    J'ai eu les mêmes problèmes avec la JVM de l'App Inventor pour Android Blocs de l'Éditeur utilise. Il définit le tas à 925m max. Ce n'est pas assez, mais je ne pouvais pas plus que d'environ 1200m d'altitude, en fonction de divers facteurs aléatoires sur ma machine.

    J'ai téléchargé tous les Soirs, la bêta du navigateur 64-bit de Firefox, et aussi JAVA 7 64 bits version.

    Je n'ai pas encore trouvé mon nouveau segment de limite, mais je viens d'ouvrir une JVM avec une taille de segment de 5900m. Pas de problème!

    Je suis sous Win 7 64 bits Ultimate sur une machine avec 24go de RAM.

    InformationsquelleAutor user1652651
  13. 0

    J'ai essayé de réglage de la taille de segment de mémoire jusqu'à 2200M sur 32 bits Linux de la machine et de la JVM a bien fonctionné. La JVM ne pas démarrer lorsque je l'ai mis à 2300M.

    • J'ai pensé que je voudrais ajouter que sur Windows VISTA 64 bits, 32 bits JVM plafonne à 1582m (-Xmx valeur). Il va se plaindre si je spécifie 1583m. Je ne sais pas si cette valeur change de machine à machine. L'ordinateur sur lequel j'ai testé ce fait a 4 GO de RAM physique.
    InformationsquelleAutor Priya
  15. 0

    un point de plus ici pour hotspot JVM 32 bits:-
    le natif de tas de capacité = 4 Gig – Java Heap - PermGen;

    Il peut devenir particulièrement difficile pour la JVM 32 bits depuis le Java Tas et des Tas natif sont dans une course. L'
    plus votre Java Heap, plus le Tas natif. Tentative d'installation d'un important Segment de mémoire pour un 32 bits VM
    e.g .2.5 GO+ augmente le risque de native OutOfMemoryError en fonction de votre demande(s) de l'empreinte,
    nombre de Threads etc.

    InformationsquelleAutor ajay29
  16. -1

    Théorique de 4 go, mais dans la pratique (par JVM IBM):

    Gagner 2k8 64, IBM Websphere Application Server 8.5.5 32bit

    C:\IBM\WebSphere\AppServer\bin>managesdk.bat -listAvailable -verbose CWSDK1003I: Доступные SDK: CWSDK1005I: Имя SDK: 1.6_32 - com.ibm.websphere.sdk.version.1.6_32=1.6 - com.ibm.websphere.sdk.bits.1.6_32=32 - com.ibm.websphere.sdk.location.1.6_32=${WAS_INSTALL_ROOT}/java - com.ibm.websphere.sdk.platform.1.6_32=windows - com.ibm.websphere.sdk.architecture.1.6_32=x86_32 - com.ibm.websphere.sdk.nativeLibPath.1.6_32=${WAS_INSTALL_ROOT}/lib/native/win /x86_32/
    CWSDK1001I: Задача managesdk выполнена успешно.
    C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2036 MaxMemory
    JVMJ9GC017E -Xmx слишком мала, должна быть не меньше 1 M байт
    JVMJ9VM015W Ошибка инициализации для библиотеки j9gc26(2): Не удалось инициализи
    ровать
    Could not create the Java virtual machine.
    C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2047M MaxMemory
    Total Memory: 4194304 (4.0 MiB)
    Max Memory: 2146435072 (2047.0 MiB)
    Free Memory: 3064536 (2.9225692749023438 MiB)
    C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2048M MaxMemory
    JVMJ9VM015W Ошибка инициализации для библиотеки j9gc26(2): Не удалось создать эк
    земпляр кучи; запрошено 2G
    Could not create the Java virtual machine.

    RHEL 6.4 64, IBM Websphere Application Server 8.5.5 32bit

    [bin]./java -Xmx3791M MaxMemory
    Total Memory: 4194304 (4.0 MiB)
    Max Memory: 3975151616 (3791.0 MiB)
    Free Memory: 3232992 (3.083221435546875 MiB)
    [root@nagios1p bin]# ./java -Xmx3793M MaxMemory
    Total Memory: 4194304 (4.0 MiB)
    Max Memory: 3977248768 (3793.0 MiB)
    Free Memory: 3232992 (3.083221435546875 MiB)
    [bin]# /opt/IBM/WebSphere/AppServer/bin/managesdk.sh -listAvailable -verbose
    CWSDK1003I: Available SDKs :
    CWSDK1005I: SDK name: 1.6_32
    - com.ibm.websphere.sdk.version.1.6_32=1.6
    - com.ibm.websphere.sdk.bits.1.6_32=32
    - com.ibm.websphere.sdk.location.1.6_32=${WAS_INSTALL_ROOT}/java
    - com.ibm.websphere.sdk.platform.1.6_32=linux
    - com.ibm.websphere.sdk.architecture.1.6_32=x86_32
    -com.ibm.websphere.sdk.nativeLibPath.1.6_32=${WAS_INSTALL_ROOT}/lib/native/linux/x86_32/
    CWSDK1001I: Successfully performed the requested managesdk task.

    InformationsquelleAutor pk.shulgin