Warum -Xmn1m -XX: SurvivorRatio = 2 macht eden Raum 0k

Question

Ich setze -Xmn1m -XX:SurvivorRatio=2, erwarte, eden Raum zu 512K zu sehen, aber tatsächlich ist es 0K.

Es ist wirklich seltsam und ich weiß nicht warum. Ich brauche deine Hilfe.

vm Optionen: -Xmx20m -Xms20m -Xmn1m -XX: SurvivorRatio = 2 -XX: + PrintGCDetails

Java-Version: 1.7.0_79

Code und Ergebnis ist wie folgt:

public class NewSizeDemo { 
    public static void main(String[] args){ 
     byte[] b = null; 

     for (int i=0; i<10; i++){ 
      b = new byte[1*1024*1024]; 
     } 
    } 
} 

Heap 
PSYoungGen  total 512K, used 0K [0x00000007fff00000, 0x0000000800000000, 0x0000000800000000) 
    eden space 0K, -2147483648% used [0x00000007fff00000,0x00000007fff00000,0x00000007fff00000) 
    from space 512K, 0% used [0x00000007fff80000,0x00000007fff80000,0x0000000800000000) 
    to space 512K, 0% used [0x00000007fff00000,0x00000007fff00000,0x00000007fff80000) 
ParOldGen  total 19456K, used 11573K [0x00000007fec00000, 0x00000007fff00000, 0x00000007fff00000) 
    object space 19456K, 59% used [0x00000007fec00000,0x00000007ff74d5a0,0x00000007fff00000) 
PSPermGen  total 21504K, used 2996K [0x00000007f9a00000, 0x00000007faf00000, 0x00000007fec00000) 
    object space 21504K, 13% used [0x00000007f9a00000,0x00000007 

Answer 1

habe ich ein paar Experimente mit Java 7 und Java 8 ein d verschiedene Optionen. Der entscheidende Punkt scheint

• Spaces sein müssen immer Größen, die ein Vielfaches von 512k sind und nicht leer sein, so dass die kleinste Einrichtung „1×512k eden, von 1×512k, zu 1×512k“ ist, was bedeutet, dass Sie habe keine neue Größe kleiner als 1536k. Außerdem kann die Verhältnisbeschränkung nur so weit wie möglich mit ganzzahligen Faktoren der Einheitsgröße 512k eingehalten werden.

• Die Zahlen sind Sie angeben, unterliegen mehrfachen von 512k Rundung und die Mindestgröße der 512k für jeden Raum durchzusetzen, die der erste Platz ist Inkonsistenzen zeigt. Z.B. mit Xmn1m mit Java 8, bekam ich eine Warnung, dass die NewSize von 1536k (anscheinend bereits angepasst) die MaxNewSize von 1024k (scheinbar noch nicht angepasst) überschreitet, die als Xmn1m soll beide auf den gleichen Wert setzen, so dass zu sagen beide sind zu klein, wäre verständlicher. Die Warnung wurde auch nur angezeigt, wenn Xmn1m, resp. Xmn1024k, die keiner Rundung unterliegen, aber nicht für Xmn1023k oder Xmn1025k gezeigt wurden.

• Da die JVM nicht mit dieser Option abstürzt, scheint die Anpassung immer zu vernünftigen Werten zu führen, aber der Code, der die Statistiken druckt, scheint Fehler zu haben (nur in Java 7) Zahlen, die tatsächlich von der JVM verwendet werden.

• Die Gesamtgröße für die junge Generation berichtet enthält immer die eden und von Raum nur, die immer leer - Raum zu ignorieren, die sich hinter den Größen berichtet an die Adressen inkonsistent ist, die die umfassen komplette Spannweite, die alle drei Räume abdeckt.

Answer 2

Dies ist ein JVM Fehler eingeführt zwischen JDK 7u40-b27 und JDK 7u40-b28.
Fehlerbericht JDK-8016309 ist nicht öffentlich zugänglich.

Vor JDK 7u40 war die minimale Größe der Heap-Region 512 Wörter (4KB).Mit den gegebenen JVM Argumente wurde die Eden Größe richtig eingestellt zu 512K:

PSYoungGen  total 768K, used 287K [0x00000000fff00000, 0x0000000100000000, 0x0000000100000000) 
    eden space 512K, 56% used [0x00000000fff00000,0x00000000fff47e08,0x00000000fff80000) 
    from space 256K, 0% used [0x00000000fffc0000,0x00000000fffc0000,0x0000000100000000) 
    to space 256K, 0% used [0x00000000fff80000,0x00000000fff80000,0x00000000fffc0000) 

JDK-6725714 erhöht die minimale Bereichsgröße auf 65536 Wörter (512 KB).
Hier ist die related change. Die gleiche Änderung hat die Dimensionierungsrichtlinie durchbrochen.
Dies führte zu Assertionsfehler in Debug-Builds von JVM:

# A fatal error has been detected by the Java Runtime Environment: 
# 
# Internal Error (/home/hotspot/src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp:183), pid=10261, tid=1081264448 
# assert(eden_size > 0 && survivor_size > 0) failed: just checking 
# 

Es war in Produkt nicht Assertionsfehler baut, sondern das seltsame Verhalten, das Sie beobachtet haben.

Das Problem wurde in JDK 8 bemerkt und behoben. Die minimal mögliche Größe der jungen Generation wurde 1536KB. Ich denke, das Update nicht geeignet war für das Zurückportieren, so dass der Fehler in späteren Updates von JDK 7.

jedoch blieb, wurde beschlossen, das Problem in JDK 7u40 release notes zu dokumentieren:

Gebiet: Hotspot/gc
Synopsis: Neue minimale junge Generation Größe ist nicht ordnungsgemäß von der JVM überprüft.

In JDK 7u40, die Mindestgröße der jungen Generation für den parallel garbage collector wurde in einem 32-Bit-JVM, und bis 1536 KB in einem 64-Bit-JVM von 192 KB bis 768 KB erhöht. Diese neue Mindestgröße wird nicht ordnungsgemäß von der JVM überprüft. Wenn eine junge Generationsgröße, die kleiner als ist, das neue Minimum in der Befehlszeile angegeben wird, kann entweder einen Absturz oder eine verschlechterte Leistung zur Folge haben.

Die Größe der jungen Generation wird durch die Optionen -XX: NewSize = und -XX: MaxNewSize = oder durch die Option -Xmn festgelegt (die letztere Option entspricht der Einstellung von NewSize und MaxNewSize). Wenn die obigen Optionen nicht verwendet werden, wird die Größe der jungen Generation als Bruchteil der maximalen Größe des Heap berechnet.

Behelfslösung: Verwenden eine junge Generation Größe, die mindestens 768 KB (für 32-Bit- JVM) oder 1536 KB (für 64-Bit-JVM).