Details
P3
Backports
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8172318 | 8u152 | David Holmes | P3 | Resolved | Fixed | b01 |
| JDK-8174023 | 8u131 | David Holmes | P3 | Resolved | Fixed | b06 |
| JDK-8174184 | emb-8u131 | David Holmes | P3 | Resolved | Fixed | b06 |
| JDK-8175149 | 8u151 | David Holmes | P3 | Resolved | Fixed | b01 |
| JDK-8175898 | 8u121 | David Holmes | P3 | Closed | Fixed | b34 |
| JDK-8177170 | 8u141 | Unassigned | P3 | Resolved | Fixed | b01 |
| JDK-8178562 | emb-8u141 | Unassigned | P3 | Resolved | Fixed | b01 |
| JDK-8180973 | openjdk7u | David Holmes | P3 | Resolved | Fixed | master |
| JDK-8183657 | 8u161 | David Holmes | P3 | Resolved | Fixed | b01 |
| JDK-8184491 | emb-8u151 | Unassigned | P3 | Resolved | Fixed | b01 |
| JDK-8185187 | 8u144 | David Holmes | P3 | Resolved | Fixed | b31 |
| JDK-8190030 | 8u162 | David Holmes | P3 | Resolved | Fixed | b04 |
| JDK-8192176 | emb-8u161 | David Holmes | P3 | Resolved | Fixed | b01 |
| JDK-8195264 | 8u172 | David Holmes | P3 | Resolved | Fixed | b03 |
| JDK-8197259 | 8u192 | David Holmes | P3 | Resolved | Fixed | team |
Description
We have an open RFE targeted to JDK 10 to get the JVM to play nicely with memory limits imposed by a Docker container (through the Linux cgroups facility): JDK-8146115
There has been a non-Oracle submission to get some basic support for this into 9:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025404.html
then:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025406.html
It is proposed for this RFE that we add an experimental VM option, such as -XX:+UseCGroupMemoryLimitForHeap, to opt-in to using the value in /sys/fs/cgroup/memory/memory.limit_in_bytes as the value for phys_mem as suggested in the submission.
This will allow us to get quick feedback from the community and customers as to how things work, and allow us to shape the full RFE for JDK 10.
There has been a non-Oracle submission to get some basic support for this into 9:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025404.html
then:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025406.html
It is proposed for this RFE that we add an experimental VM option, such as -XX:+UseCGroupMemoryLimitForHeap, to opt-in to using the value in /sys/fs/cgroup/memory/memory.limit_in_bytes as the value for phys_mem as suggested in the submission.
This will allow us to get quick feedback from the community and customers as to how things work, and allow us to shape the full RFE for JDK 10.
Issue Links
- relates to
-
JDK-8146115
Improve docker container detection and resource configuration usage
-
Activity
URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/5f1d1df0ea49
User: dholmes
Date: 2016-12-13 00:59:04 +0000
User: dholmes
Date: 2016-12-13 00:59:04 +0000
In looking at the backport to 8u I realized that this effort served very little purpose. The user can just as easily specify:
-XX:MaxRAM=`cat /sys/fs/cgroup/memory/memory.limit_in_bytes`
to get the same results.
-XX:MaxRAM=`cat /sys/fs/cgroup/memory/memory.limit_in_bytes`
to get the same results.
First of all that's cumbersome, and secondly it will blow up for naive users if there is no memory.limit_in_bytes file. This fix is very localized and will not hurt anyone and will save our customer's some headaches.
Okay - a request for enhancement backport approval for 8u has been sent to jdk8u-dev@openjdk.java.net
URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5f1d1df0ea49
User: lana
Date: 2016-12-21 16:40:09 +0000
User: lana
Date: 2016-12-21 16:40:09 +0000
----------------------------
As noted we had planned a full RFE for 10 when we had more time to fully explore working with cgroup limits. But there is growing demand for the JVM to be able to function within Docker containers that impose memory limits, today. By providing an experimental option to allow this interaction we can address this current request and also gather feedback and information to help shape the full RFE for 10.
As an opt-in experimental flag there is zero risk for anyone not running with the flag set.
Testing of this flag will be manual and ad-hoc, there is no proposal to include this as a testing mode for an existing test processes.