RFR(XS): 8194232: Container memory not properly recognized.

Bob Vandette bob.vandette at oracle.com
Wed Jan 3 18:54:37 UTC 2018


> On Jan 3, 2018, at 2:43 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi Bob, 
> 
> The value is read from the file system as jlong. 
> I think making the reading of the value as jlong or julong 
> depend on the kernel version is not a good idea. 

I agree that we shouldn't make the solution based on the running kernel version.

> 
> So should I test for 
>   memlimit < 0 || memlimit >  LONG_MAX / os::vm_page_size() * os::vm_page_size()
> and get rid of the constant altogether?

I was thinking that we could change the type read from the file system to a julong and then just
use memlimit >  LONG_MAX / os::vm_page_size() * os::vm_page_size().  You’ll need to
add a (jlong) cast but since we’re checking for > LONG_MAX, there will be no precision
lost.

Something like this:

--- a/src/hotspot/os/linux/osContainer_linux.cpp
+++ b/src/hotspot/os/linux/osContainer_linux.cpp
@@ -31,16 +31,12 @@
 #include "logging/log.hpp"
 #include "osContainer_linux.hpp"
 
-/*
- * Warning: Some linux distros use 0x7FFFFFFFFFFFF000
- * and others use 0x7FFFFFFFFFFFFFFF for unlimited.
- */
-#define UNLIMITED_MEM CONST64(0x7FFFFFFFFFFFF000)
 
 #define PER_CPU_SHARES 1024
 
 bool  OSContainer::_is_initialized   = false;
 bool  OSContainer::_is_containerized = false;
+julong _unlimited_memory;
 
 class CgroupSubsystem: CHeapObj<mtInternal> {
  friend class OSContainer;
@@ -217,6 +213,8 @@
   _is_initialized = true;
   _is_containerized = false;
 
+  _unlimited_memory = (LONG_MAX / os::vm_page_size()) * os::vm_page_size();
+
   log_trace(os, container)("OSContainer::init: Initializing Container Support");
   if (!UseContainerSupport) {
     log_trace(os, container)("Container Support not enabled");
@@ -419,37 +417,37 @@
  *    OSCONTAINER_ERROR for not supported
  */
 jlong OSContainer::memory_limit_in_bytes() {
-  GET_CONTAINER_INFO(jlong, memory, "/memory.limit_in_bytes",
-                     "Memory Limit is: " JLONG_FORMAT, JLONG_FORMAT, memlimit);
+  GET_CONTAINER_INFO(julong, memory, "/memory.limit_in_bytes",
+                     "Memory Limit is: " JULONG_FORMAT, JULONG_FORMAT, memlimit);
 
-  if (memlimit >= UNLIMITED_MEM) {
+  if (memlimit >= _unlimited_memory) {
     log_trace(os, container)("Memory Limit is: Unlimited");
     return (jlong)-1;
   }
   else {
-    return memlimit;
+    return (jong)memlimit;
   }
 }
 
 jlong OSContainer::memory_and_swap_limit_in_bytes() {
-  GET_CONTAINER_INFO(jlong, memory, "/memory.memsw.limit_in_bytes",
-                     "Memory and Swap Limit is: " JLONG_FORMAT, JLONG_FORMAT, memswlimit);
-  if (memswlimit >= UNLIMITED_MEM) {
+  GET_CONTAINER_INFO(julong, memory, "/memory.memsw.limit_in_bytes",
+                     "Memory and Swap Limit is: " JULONG_FORMAT, JULONG_FORMAT, memswlimit);
+  if (memswlimit >= _unlimited_memory) {
     log_trace(os, container)("Memory and Swap Limit is: Unlimited");
     return (jlong)-1;
   } else {
-    return memswlimit;
+    return (jlong)memswlimit;
   }
 }
 
 jlong OSContainer::memory_soft_limit_in_bytes() {
-  GET_CONTAINER_INFO(jlong, memory, "/memory.soft_limit_in_bytes",
-                     "Memory Soft Limit is: " JLONG_FORMAT, JLONG_FORMAT, memsoftlimit);
-  if (memsoftlimit >= UNLIMITED_MEM) {
+  GET_CONTAINER_INFO(julong, memory, "/memory.soft_limit_in_bytes",
+                     "Memory Soft Limit is: " JULONG_FORMAT, JULONG_FORMAT, memsoftlimit);
+  if (memsoftlimit >= _unlimited_memory) {
     log_trace(os, container)("Memory Soft Limit is: Unlimited");
     return (jlong)-1;
   } else {
-    return memsoftlimit;
+    return (jlong)memsoftlimit;
   }
 }
Bob.

> Instead, I would implement a method is_unlimited_memory(memlimit).
> 
> I don't want to make the change too big, as I need to get it fixed in 10.
> 
> Best regards,
>  Goetz.
> 
>> -----Original Message-----
>> From: Bob Vandette [mailto:bob.vandette at oracle.com]
>> Sent: Dienstag, 2. Januar 2018 17:10
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> Cc: Doerr, Martin <martin.doerr at sap.com>; hotspot-runtime-
>> dev at openjdk.java.net
>> Subject: Re: RFR(XS): 8194232: Container memory not properly recognized.
>> 
>> I just read that unlimited may be one of these possible values depending on
>> Kernel version.
>> 
>> LONG_MAX (Linux Kernel Version < 3.1.2)
>> ULONG_MAX (3.12 <= Linux Kernel Version < 3.19)
>> LONG_MAX / pagesize * pagesize (Linux Kernel Version >= 3.19)
>> 
>> Assuming os::page_size() is initialized before the container init, we should
>> calculate
>> the unlimited value based on this and take the ULONG_MAX situation into
>> consideration.
>> 
>> Bob.
>> 
>> 
>>> On Dec 27, 2017, at 6:24 AM, Lindenmaier, Goetz
>> <goetz.lindenmaier at sap.com> wrote:
>>> 
>>> Hi Martin,
>>> 
>>> Yes, I also figured that the constant is one system page less than max long.
>>> If the system pages are > 64K, this constant will be too small, again.
>>> But I'm not sure whether adding 8 zeros is right thing to do in ramp down
>> phase.
>>> 
>>> Best regards,
>>> Goetz.
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Doerr, Martin
>>>> Sent: Mittwoch, 27. Dezember 2017 12:10
>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>>>> dev at openjdk.java.net
>>>> Subject: RE: RFR(XS): 8194232: Container memory not properly
>> recognized.
>>>> 
>>>> Hi Götz,
>>>> 
>>>> thanks for fixing it.
>>>> 
>>>> I wonder if 4 zeroes will be sufficient on all linux distros in the long run.
>> Does
>>>> anything speak against using e.g. 8 zeroes?
>>>> 
>>>> Best regards,
>>>> Martin
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
>>>> bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
>>>> Sent: Mittwoch, 27. Dezember 2017 11:38
>>>> To: hotspot-runtime-dev at openjdk.java.net
>>>> Subject: RFR(XS): 8194232: Container memory not properly recognized.
>>>> 
>>>> Hi
>>>> 
>>>> Please review and sponsor this tiny fix. It needs to go to jdk10.
>>>> http://cr.openjdk.java.net/~goetz/wr17/8194232-
>>>> ppcle_unlimited/webrev.01/
>>>> 
>>>> TestAggressiveHeap.java fails because the container recognition
>>>> misinterprets the available memory size. On SLES 12.1 ppc64le,
>>>> GET_CONTAINER_INFO() sets memlimit to 0x7FFFFFFFFFFF0000. This
>>>> is compared to UNLIMITED_MEM == 0x7FFFFFFFFFFFF000, making
>>>> the VM believe memory is _not_ unlimited.
>>>> 
>>>> Best regards,
>>>> Goetz.
>>> 
> 



More information about the hotspot-runtime-dev mailing list