Ich verwende eine 64-Bit Java 1.8 Hotspot JVM von Oracle. Ich habe versucht, meinen Kopf um einen Unterschied im Verhalten von JVM zu wickeln in komprimierten Objektzeigern zu treten, wenn verschiedene GC-Mechanismen verwendet werden. Zum Beispiel:UseCompressedOops Kick-In-Schwelle unterschiedlich für G1 und CMS
$ java -XX:+UseConcMarkSweepGC -XX:+PrintFlagsFinal -Xms32766m -Xmx32766m
bool UseCompressedClassPointers := true {lp64_product}
bool UseCompressedOops := true {lp64_product}
$ java -XX:+UseConcMarkSweepGC -XX:+PrintFlagsFinal -Xms32767m -Xmx32767m
bool UseCompressedClassPointers = false {lp64_product}
bool UseCompressedOops = false {lp64_product}
$ java -XX:+UseG1GC -XX:+PrintFlagsFinal -Xms32736m -Xmx32736m
bool UseCompressedClassPointers := true {lp64_product}
bool UseCompressedOops := true {lp64_product}
$ java -XX:+UseG1GC -XX:+PrintFlagsFinal -Xms32737m -Xmx32737m
bool UseCompressedClassPointers = false {lp64_product}
bool UseCompressedOops = false {lp64_product}
Ich habe versucht, ein paar anderen G1GC Knöpfe ändern, aber nicht komprimieren Zeiger Optimierung für Speichergrößen über 32.736 MB für G1 tritt in bekommen. Aber wie Sie sehen können, kann CMS komprimierte Zeiger für Heap-Größen bis zu 32766 MB verwenden. Ich versuche zu verstehen, was diese Schwelle für verschiedene GC-Algorithmen steuert.
Ist der G1-Flag in dem letzten Befehl '-XX: + G1GC' einen Tippfehler? – IceMan
@IceMan Ja, es war, vielen Dank für den Hinweis it out. Ich habe es gerade korrigiert. –