RFR: 8300645: Revert julong changes from 8194232 after 8292083

[Severin Gehwolf]

On Tue, 24 Jan 2023 13:16:31 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this change to Hotspot's container detection code. The core API of `OSContainer` uses `jlong` and should therefore also use `jlong` for reading values from the cgroup files. This fixes an oddity where on error, i.e. a file doesn't exist a negative number is being returned from the `GET_CONTAINER_INFO` macro, which potentially logs values. This results in incorrect log output as `-2` gets converted to `unsigned long` and printed according to that format.
> 
> The bug which introduced this change was [JDK-8194232](https://bugs.openjdk.org/browse/JDK-8194232) which was an attempt to deal with the fact that the cgroup v1 interface files might contain large numbers if no limit is in place. Since the memory limits are bound above by the physical host values after  [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083) there is no need to "guess" what an unlimited value means any longer. If it's larger or equal to physical, treat it as unlimited.
> 
> Therefore, I propose to revert changes from [JDK-8194232](https://bugs.openjdk.org/browse/JDK-8194232) and handle comparisons to `unsigned long` values accordingly in the implementation. This avoids confusing trace output on some systems.
> 
> Testing:
> - [x] Container tests on x86_64 fastdebug with cgroup v1 (legacy), with and without `swapaccount=0`.
> - [x] Container tests on x86_64 fastdebug with cgroup v2 (unified), with and without `swapaccount=0`.
> - [x] Added regression test. Fails on cg v1 with `swappaccount=0` on unpatched. Passes after this patch.
> - [x] GHA (only unrelated failures in [compiler/vectorization/runner*](https://github.com/jerboaa/jdk/actions/runs/3989491372#user-content-compiler_vectorization_runner_arrayindexfilltest) on x86 - 32 bit and MacOSX x64)

@iklam Could you perhaps help review this?

-------------

PR: https://git.openjdk.org/jdk/pull/12166