Modify wording relating to HotSpot JVM compressed oops

[jasontedor]

This commit modifies the wording around using compressed oops on the
HotSpot JVM. In particular, an attempt is made to make clear that the
boundary is not exact, to remove the usage of floating point numbers as
this can confuse people when trying to set their max heap size on the
JVM, and to provide documentation for how to check whether or not the
provided settings enable or disable compressed oops.

Relates elastic/elasticsearch#15445

[jasontedor]

Would @clintongormley or @polyfractal mind taking a look?

[clintongormley]

I'd make this a TIP block, just add TIP: at the beginning of the sentence.

[clintongormley]

Is there any easy way to know what the cutoff is for a particular JVM? Or to know if you've crossed the boundary on a running JVM?

[polyfractal]

I believe the motivation for the change from "~32gb" -> "30.5gb" was to ensure that everyone benefitted from compressed OOPs regardless of their individual JVMs. E.g. when you read "just under 32gb", most people will set it to "31.9" or similar and may/may not benefit from the compressed oops.

So someone (@markwalkom I think?) made the change to give enough wiggle room to always work. I didn't realize decimals were disallowed though. I wonder if we should make a note somewhere about that too?

Perhaps we can explain "a little under 32gb" a bit more in the Tip? I just want to make sure people don't read this and say "Ok, i'll set it to 31.999 since that's just under".

Maybe expand the Tip to something like this?

*note: pre-coffee, no claims of beautiful prose :) *

---

Just how far under 32gb should I set the JVM?

Unfortunately, that depends. The exact cutoff varies by JVMs and platforms. If you want to play it safe, setting the heap to 31gb is likely safe. Alternatively, you can verify the cutoff point for the HotSpot JVM by adding -XX:+PrintFlagsFinal to your JVM options and checking that the value of the UseCompressedOops flag is true. This will let you find the exact cutoff for your platform and JVM.

For example, here we test a Java 1.7 installation on MacOSX and see the max heap size is around 32600mb (~31.83gb) before compressed pointers are disabled:

$ JAVA_HOME=`/usr/libexec/java_home -v 1.7` java -Xmx32600m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops
     bool UseCompressedOops   := true   
$ JAVA_HOME=`/usr/libexec/java_home -v 1.7` java -Xmx32766m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops
     bool UseCompressedOops   = false 

In contrast, a Java 1.8 installation on the same machine has a max heap size around 32766mb (~31.99gb):

$ JAVA_HOME=`/usr/libexec/java_home -v 1.8` java -Xmx32766m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops
     bool UseCompressedOops   := true
$ JAVA_HOME=`/usr/libexec/java_home -v 1.8` java -Xmx32767m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops
     bool UseCompressedOops   = false

The morale of the story is that the exact cutoff for max heap size in bytes that allows compressed oops varies from JVM to JVM, so take caution when taking examples from elsewhere and be sure to check your system with your configuration and your JVM.

[polyfractal]

Also, tangentially, is there a way we can have ES spit out this information in the startup log? That'd really be the most user-friendly option.

[jasontedor]

Is there any easy way to know what the cutoff is for a particular JVM?

@clintongormley Not anything straightforward that I'm aware of.

Or to know if you've crossed the boundary on a running JVM?

On a running JVM, you can check the status of UseCompressedOops with

$ jinfo -flag UseCompressedOops <pid>
-XX:-UseCompressedOops

if UseCompressedOops is disabled and

$ jinfo -flag UseCompressedOops <pid>
-XX:+UseCompressedOops

if UseCompressedOops is enabled.

[jasontedor]

Or to know if you've crossed the boundary on a running JVM?

Also, tangentially, is there a way we can have ES spit out this information in the startup log?

@clintongormley @polyfractal I've opened elastic/elasticsearch#15489 to get the status of UseCompressedOops output in the logs on startup, and provide the same in the JVM info available through the nodes info API.

[polyfractal]

Sorry for the delay on this. I expanded the "empirically testing" portion a bit and just merged. Thanks!