RFR: 8300645: Revert julong changes from 8194232 after 8292083

[Johan Sjölen]

On Mon, 13 Feb 2023 17:08:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 94:
>> 
>>> 92:   GET_CONTAINER_INFO(jlong, _memory->controller(), "/memory.limit_in_bytes",
>>> 93:                      "Memory Limit is: " JLONG_FORMAT, JLONG_FORMAT, memlimit);
>>> 94:   assert(memlimit > 0, "invariant");
>> 
>> This doesn't seem right to me. If parsing from this file can give us a negative number, then we ought to deal with that case explicitly on all builds.
>
> The thing with `GET_CONTAINER_INFO` is that it's a preprocessor macro which might trigger a short return. So this cannot happen (currently). The assert is a safeguard. I'm not sure we need this handled in product code. Thoughts?

Surely it can happen because `subsystem_file_line_contents` may successfully parse `-1` into a `jlong`? Assuming that the file can contain a negative number. I don't think I understand why we have the safeguard there otherwise.

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

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