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

[Bob Vandette]

Ok, looks like the problem doesn’t impact the hotspot code.

Your change looks good to me.

Thanks for checking,
Bob.



> On Jul 26, 2019, at 2:55 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> Hi Bob, my change  only touches the test coding .
> 
> test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java
> 
> I am not aware of  related issues in the HS code,  but I have not checked much .
> This is what  java gives me on the system :
> 
> java  -XshowSettings:system -version
> 
> Operating System Metrics:
>    Provider: cgroupv1
>    Effective CPU Count: 8
>    CPU Period: 100000us
>    CPU Quota: -1
>    CPU Shares: -1
>    List of Processors, 8 total: 
>    0 1 2 3 4 5 6 7 
>    List of Effective Processors, 0 total: 
>        List of Memory Nodes, 1 total: 
>    0 
>    List of Available Memory Nodes, 0 total: 
>        CPUSet Memory Pressure Enabled: false
>    Memory Limit: Unlimited
>    Memory Soft Limit: Unlimited
>    Memory & Swap Limit: 0.00K
>    Kernel Memory Limit: 0.00K
>    TCP Memory Limit: 0.00K
>    Out Of Memory Killer Enabled: true
> 
> Best regards, Matthias
> 
> 
>> 
>> 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
>>>>> 
>