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

[Baesken, Matthias]

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
> >