RFR(XS): 8194232: Container memory not properly recognized.
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Wed Jan 3 07:43:41 UTC 2018
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.
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?
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