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(NumberFormatException.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(MetricsTester.java:160)
at jdk.test.lib.containers.cgroup.MetricsTester.testMemorySubsystem(MetricsTester.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(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.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 .
We get the value while fetching memory "limit_in_bytes" from /proc .
I noticed in some C coding dealing with it, that it might be “unsigned long long int” , so Long.MAX_VALUE is maybe not sufficient .
Some more info about the unsigned long long int :
https://www.redhat.com/archives/libvir-list/2013-December/msg00435.html

At java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java
a similar case is handled :
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