You can run with -XX:+PrintFlagsFinal to print the values of all flags at startup of the JVM. Alternatively, you can use the jinfo tool to check the value of a flag in a running JVM: > jinfo -flag UseCompressedOops 7364 -XX:+UseCompressedOops Use jps to find the pid of the process.
The reason why Java reserves 1G for Classes hides in the way how it manages compressed class pointers. The long answer: read this doc https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/considerations.html The short answer: setup the correct size in ‘CompressedClassSpaceSize’ property -XX:CompressedClassSpaceSize=300m
The flag has a default of true and it will be set to false if the detection fails, so you can simply use +PrintFlagsFinal to see if it is used: My Laptop without AES-NI: C:\>”C:\Program Files\Java\jdk1.7.0_51\bin\java” -XX:+PrintFlagsFinal -version | find “UseAES” bool UseAES = false {product} bool UseAESIntrinsics = false {product} java version “1.7.0_51” Java(TM) … Read more
That must be the thread-local handshake poll. Look where %r11 is read from. If it is read from some offset off the %r15 (thread-local storage), that’s the guy. See the example here: 0.31% ↗ …70: movzbl 0x94(%r9),%r10d 0.19% │ …78: mov 0x108(%r15),%r11 ; read the thread-local page addr 25.62% │ …7f: add $0x1,%rbp 35.10% │ … Read more
You can use java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version to print all options and their defaults. If you have a debug build you can use this command to print comments for the various options as well: java -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -XX:+PrintFlagsWithComments -version PS: There are descriptions for most of them in this blog post: http://stas-blogspot.blogspot.bg/2011/07/most-complete-list-of-xx-options-for.html
Generally speaking, it’s always preferable to let HotSpot compiler tune itself. Even using Server VM (-server) is default for 64bits and some ‘server-class’ machines. -Xbatch was intended mostly for debugging as described in Steve Goldman’s blog you pointed: So the -Xbatch switch is not a particularly useful switch even in the pre-mustang days. It is … Read more
Not a full answer, I simply don’t have time to do the detailed benchmarks your question needs but hopefully useful. Know your enemy You are targeting a combination of the JVM (in essence the JIT) and the underlying CPU/Memory subsystem. Thus “This is faster on JVM X” is not likely to be valid in all … Read more
From sun.misc.VM, it’s Runtime.getRuntime.maxMemory(), that’s what is configured with -Xmx. E. g. if you don’t configure -XX:MaxDirectMemorySize and do configure -Xmx5g, the “default” MaxDirectMemorySize will also be 5 Gb, and the total heap+direct memory usage of the app may grow up to 5 + 5 = 10 Gb.
HotSpot compilation policy is rather complex, especially for Tiered Compilation, which is on by default in Java 8. It’s neither a number of executions, nor a matter of CompileThreshold parameter. The best explanation (apparently, the only reasonable explanation) can be found in HotSpot sources, see advancedThresholdPolicy.hpp. I’ll summarize the main points of this advanced compilation … Read more
I’ve pulled together some info on this on my blog. A Cliff Click comment I found says: Zombie methods are methods whose code has been made invalid by class loading. Generally the server compiler makes aggressive inlining decisions of non-final methods. As long as the inlined method is never overridden the code is correct. When … Read more