RFR [XS]: 8228585: jdk/internal/platform/cgroup/TestCgroupMetrics.java - NumberFormatException because of large long values (memory limit_in_bytes)

[Bob Vandette]

Matthias,

Does this issue impact the VM Container code “jdk/open/src/hotspot/os/linux/osContainer_linux.cpp”?

Do we properly detect unlimited?

Try running “java -XshowSettings:system -version

Bob.


> On Jul 25, 2019, at 5:06 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> Thank's fort he review .
> 
> Bob, are  you fine with my change too ?
> 
> Best regards, Matthias
> 
> 
>> -----Original Message-----
>> From: David Holmes <david.holmes at oracle.com>
>> Sent: Donnerstag, 25. Juli 2019 10:21
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>> Subject: Re: RFR [XS]: 8228585:
>> jdk/internal/platform/cgroup/TestCgroupMetrics.java -
>> NumberFormatException because of large long values (memory
>> limit_in_bytes)
>> 
>> Hi Matthias,
>> 
>> Looks like a good fix.
>> 
>> Minor nit:
>> 
>> !             // In this case, return Long.max
>> 
>> s/max/MAX_VALUE
>> 
>> Thanks,
>> David
>> 
>> On 25/07/2019 5:47 pm, Baesken, Matthias wrote:
>>> Hello, please review this small  test related  fix .
>>> 
>>> On some linux x86_64   machine  we run in  the test
>> "jdk/internal/platform/cgroup/TestCgroupMetrics.java"   into this
>> NumberFormatException  :
>>> 
>>> java.lang.NumberFormatException: For input string:
>> "18446744073709551615"
>>> at
>> java.base/java.lang.NumberFormatException.forInputString(NumberFormat
>> Exception.java:68)
>>> at java.base/java.lang.Long.parseLong(Long.java:699)
>>> at java.base/java.lang.Long.parseLong(Long.java:824)
>>> at
>> jdk.test.lib.containers.cgroup.MetricsTester.getLongValueFromFile(MetricsT
>> ester.java:160)
>>> at
>> jdk.test.lib.containers.cgroup.MetricsTester.testMemorySubsystem(Metrics
>> Tester.java:223)
>>> at TestCgroupMetrics.main(TestCgroupMetrics.java:50)
>>> at
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>>> at
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet
>> hodAccessorImpl.java:62)
>>> at
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega
>> tingMethodAccessorImpl.java:43)
>>> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
>>> at
>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapp
>> er.java:127)
>>> at java.base/java.lang.Thread.run(Thread.java:830)
>>> 
>>> I checked the number   "18446744073709551615" and it seems to be larger
>> than Long.MAX_VALUE  .
>>> Background is that we seem to deal  with  unsigned long long ints where
>> Java Long is not always sufficient .
>>> 
>>> 
>>> There has been similar handling  done  here  where  in case of overflow  we
>> "round"  to   Long.MAX_VALUE  :
>>> 
>>> java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java
>>> 
>>> 127    public static long convertStringToLong(String strval) {
>>> 128        long retval = 0;
>>> 129        if (strval == null) return 0L;
>>> 130
>>> 131        try {
>>> 132            retval = Long.parseLong(strval);
>>> 133        } catch (NumberFormatException e) {
>>> 134            // For some properties (e.g. memory.limit_in_bytes) we may
>> overflow the range of signed long.
>>> 135            // In this case, return Long.max
>>> 
>>> And I do the same now in the test coding .
>>> 
>>> 
>>> 
>>> Bug/webrev :
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8228585
>>> 
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8228585.0/
>>> 
>>> 
>>> Thanks, Matthias
>>>