JDK-8300645 : Handle julong values in logging of GET_CONTAINER_INFO macros
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • Submitted: 2023-01-19
  • Updated: 2023-02-23
  • Resolved: 2023-02-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 21
21 b11Fixed
Related Reports
Relates :  
JDK-8300658 - memory_and_swap_limit() reporting wrong values on systems with swapaccount=0
Description
JDK-8194232 tried to fix a similar case to JDK-8292083, but still got it wrong for some cases. As JDK-8292083 bounds the memory limit above by the host total memory, we no longer need changes from JDK-8194232. In fact that old fix amounts to confusing trace output when GET_CONTAINER_INFO returns negative values (like OS_CONTAINER_ERROR, -2) on some systems. See JDK-8299424 for such a symptom:

[0.163s][trace][os,container] Memory and Swap Limit is: 18446744073709551614
memory_and_swap_limit_in_bytes: not supported

During review it was pointed out to better fix the GET_CONTAINER_INFO macros to properly handle logging of julong types in order to avoid those confusing trace logs.
Comments
Changeset: 53ae4c07 Author: Severin Gehwolf <sgehwolf@openjdk.org> Date: 2023-02-16 10:08:54 +0000 URL: https://git.openjdk.org/jdk/commit/53ae4c07fda69358fc0b2edadf8dbfe6428de619
16-02-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/12166 Date: 2023-01-24 13:16:31 +0000
24-01-2023