Warum bin ich in der Lage,- Xmx auf einen Wert größer als physischen und virtuellen Speicher auf der Maschine auf Windows-und Solaris?
Auf einem 64-bit-Windows-Maschine mit 12 GB RAM und 33GB Virtuellen Speicher (per Task-Manager), bin ich in der Lage zum ausführen von Java (1.6.0_03-b05) mit einem unmöglich -Xmx Einstellung von 3,5 TB, aber es funktioniert nicht mit 35TB. Was ist die Logik hinter, wenn es funktioniert und wenn es scheitert? Der Fehler bei 35TB scheint zu implizieren, dass es versucht, um Plätze zu reservieren beim Start. Warum würde es tun, für -Xmx (im Gegensatz zu -Xms)?
C:\temp>java -Xmx3500g ostest os.arch=amd64 13781729280 Bytes RAM C:\temp>java -Xmx35000g ostest Fehler während der Initialisierung aufgetreten ist der VM Could not reserve enough space for object heap Could not create the Java virtual machine.
Unter Solaris (4GB RAM, Java 1.5.0_16), habe ich ziemlich viel aufgegeben auf 1 PB auf, wie hoch ich das einstellen kann -Xmx. Ich verstehe nicht die Logik, wenn es wird ein Fehler ausgegeben, der auf die -Xmx Einstellung.
devsun1.mgo:/export/home/mgo - > java -d64 -Xmx1000000g ostest os.arch=sparcv9 4294967296 Bytes RAM
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.
Mindestens mit der Sonne 64-bit-VM 1.6.0_17 für Windows, ObjectStartArray::initialize weisen 1 byte für jede 512 bytes des heap auf VM starten. Starten der VM mit 35TB heap verursachen wird, der VM zuweisen 70 GB eingerichtet und sofort damit scheitern auf Ihrem system.
Den 32-bit-VM (und ich nehme an, dass die 64-bit-VM) von Sun nicht berücksichtigt für verfügbare physikalische Speicher bei der Berechnung der maximum-heap, sondern nur von der 2 GB adressierbaren Speicher auf Windows-und Linux-oder 4GB auf Solaris oder evtl. fehlerhaften genügend Speicher beim Start für den management-Bereich.
Wenn Sie darüber nachdenken, die überprüfung der geistigen Gesundheit der max-heap-Wert gegen die verfügbaren physischen Speicher macht nicht viel Sinn. X GB physischen Speicher bedeutet nicht, dass X GB ist verfügbar, um die VM, wenn erforderlich, es können genauso gut verwendet wurden, durch andere Prozesse, so dass die VM braucht einen Weg, um mit der situation umzugehen, dass mehr heap benötigt wird als zur Verfügung aus dem OS sowieso. Wenn der VM ist nicht gebrochen, OutOfMemoryErrors geworfen werden, wenn der Speicher nicht zugeordnet werden kann, von der OS -, als wenn die max-heap-Größe erreicht wurde.
Laut dieser thread auf Sun ' s java-Foren (die OP hat 16 GB physischen Speicher):
UPDATE: googelte ich ein bisschen weiter und, nach dem Häufig Gestellte Fragen Über die Java-HotSpot-VM und genauer Wie groß ein Haufen kann ich mit einem 64-bit-VM?
Ich weiß nicht, warum Sie sind in der Lage, zum starten einer JVM mit einem heap - >45 GB. Das ist ein bisschen verwirrend...
Nur re-Durchsetzung Pascal Antwort--sehr vorsichtig Sein, in windows-wenn Sie eine hohe maximale Speicherausbau. Ich arbeite an einem server-Projekt benötigt, wie viel physischen Speicher wie möglich, aber wenn man einmal über den physischen ram, grottenschlechte performance ist nicht eine gute Beschreibung von dem, was passiert--Hung der Maschine könnte besser sein.
Was passiert (zumindest ist dies meine Einschätzung des es nach Tagen der Prüfung der Protokolle und re-tests) ist Windows der ram ausgeht, und fordert alle apps frei, was Sie können. Wenn es fragt, Java, Java startet eine GC. Die GC betrifft alle Speicher (was nichts wurde ausgelagert werden vertauscht). Dies wiederum bewirkt, dass windows nicht genügend Arbeitsspeicher. Windows sendet dann eine Nachricht an alle apps, die er Ihnen frei, was Sie können.... (recurse auf unbestimmte Zeit)
Dies kann EIGENTLICH nicht sein, was Los ist, aber die Tatsache, dass Java-GC berührt Sehr Alte Erinnerung an Zeiten macht es unvereinbar mit paging.