JDK-8213175 : Java ergonomics limits heap to 32GB to allow compressed oops
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11.0.1,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86_64
  • Submitted: 2018-10-30
  • Updated: 2019-08-15
  • Resolved: 2019-05-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 13
13Resolved
Related Reports
Relates :  
Relates :  
Description
A DESCRIPTION OF THE PROBLEM :
I'm running java in a docker container on a machine with 32 cores and 120GB ram. If I specify the heap size with Xmx, I can make use of all of that ram. If I specify it with -XX:+UseContainerSupport and -XX:MaxRAMPercentage, I get a MaxHeapSize of at most 32178700288, no matter the parameters I pass to java or docker. I can easily restrict the heap size to *below* 32178700288, but it refuses to ever to above.

As we can see from the output of these commands, anything where the target heap size would be above 32178700288 hit the limit.

$ docker run -it --rm -m 96g openjdk:11 java -XX:MaxRAMPercentage=95 -XX:+PrintFlagsFinal -XX:+UnlockExperimentalVMOptions +XX:+UseContainerSupport  -version | grep MaxHeapSize
   size_t MaxHeapSize                              = 32178700288                               {product} {ergonomic}

$ docker run -it --rm -m 16g openjdk:11 java -XX:MaxRAMPercentage=95 -XX:+PrintFlagsFinal -XX:+UnlockExperimentalVMOptions +XX:+UseContainerSupport  -version | grep MaxHeapSize
   size_t MaxHeapSize                              = 16322134016                               {product} {ergonomic}

$ docker run -it --rm -m 96g openjdk:11 java -XX:MaxRAMPercentage=50 -XX:+PrintFlagsFinal -XX:+UnlockExperimentalVMOptions +XX:+UseContainerSupport  -version | grep MaxHeapSize
   size_t MaxHeapSize                              = 32178700288                               {product} {ergonomic}

$ docker run -it --rm -m 16g openjdk:11 java -XX:MaxRAMPercentage=50 -XX:+PrintFlagsFinal -XX:+UnlockExperimentalVMOptions +XX:+UseContainerSupport  -version | grep MaxHeapSize
   size_t MaxHeapSize                              = 8589934592                                {product} {ergonomic}


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
* Create a docker machine with a lot of ram (for my tests, it was a n1-standard-32 in gloud
* Run: docker run -it --rm -m 96g openjdk:11 java -XX:MaxRAMPercentage=95 -XX:+PrintFlagsFinal -XX:+UnlockExperimentalVMOptions +XX:+UseContainerSupport  -version  | grep MaxHeapSize
* Value shows: 32178700288                               

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Value should show a value that is much larger, presumably 95% of 96gb, minus any other reserved thing.
ACTUAL -
32178700288 bytes                              

---------- BEGIN SOURCE ----------
docker run -it --rm -m 96g openjdk:11 java -XX:MaxRAMPercentage=95 -XX:+PrintFlagsFinal -XX:+UnlockExperimentalVMOptions +XX:+UseContainerSupport  -version  | grep MaxHeapSize
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
 docker run -it --rm -m 96g openjdk:11 java -XX:+PrintFlagsFinal -Xmx90G -XX:-UseContainerSupport -version  | grep MaxHeapSize
   size_t MaxHeapSize                              = 96636764160                               {product} {command line}




Comments
duplicate of https://bugs.openjdk.java.net/browse/JDK-8222252. Will fix this problem under that Jira Issue.
10-05-2019

The problem is related to CompressedOops. If CompressedOops is disabled, you get the expected results. CompressedOops gets automatically disabled if you specify -Xmx90G. docker run -it --rm -m 96g openjdk:11 java -XX:MaxRAMPercentage=95 -XX:-UseCompressedOops -XX:+PrintFlagsFinal -version | grep MaxHeapSize size_t MaxHeapSize = 97928609792 {product} {ergonomic} BTW: You don't need to specify -XX:+UseContainerSupport. This is the default if we detect we are running in a container.
31-10-2018

Can we get the same experiments with -Xlog:os=trace ? An important line of logging is missing due to not being marked as (os,container). Thanks.
31-10-2018

The attachments are badly formatted and very hard to read - no line breaks! This may be significant in 118Limit_120G: WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap. I don't understand why the logging is repeated so many times. Assigning to [~bobv] for initial analysis.
31-10-2018

We need to see what container limits the VM thinks are present. Can the submitter please run: java -Xlog:os+container=trace -version and report the output.
31-10-2018

Additional information from submitter # With the same 96g limit as the other trials. This is on a machine with 120gb of physical ram 96Glimit_120G (attached file) # With no specified limit. This is on a machine with 120gb of physical ram nolimit_120G # With the same limit specified that `docker stats --all` gives us, 118GB. This is on a machine with 120gb of physical ram 118Limit_120G
31-10-2018