RFR: 8300645: Handle julong values in logging of GET_CONTAINER_INFO macros [v2]

[Severin Gehwolf]

On Mon, 13 Feb 2023 18:26:45 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Fix the GET_CONTAINER_INFO macro
>>    
>>    Previously it would not take in a log_fmt argument and would, therefore,
>>    format OS_CONTAINER_ERROR according to the log format string passed in,
>>    potentially being JULONG_FORMAT. Now with the format passed in
>>    explicitly it's possible to use a different format for the log line
>>    if OS_CONTAINER_ERROR is being returned ('%d'). For the actual log line
>>    in the non-error case no observable differences would be seen.
>>    
>>    NOTE: GET_CONTAINER_INFO_LINE would not need the change as it's not
>>    logging OS_CONTAINER_ERROR with a user-supplied format.
>>  - Remove conditional in trace log call
>>  - Reboot patch to original but keep reg-test
>>  - Revert "Refactor checked values reading into separate functions"
>>    
>>    This reverts commit 627e07067fefb0a44f8d6d14b3c4843b20e92bcb.
>>  - Merge branch 'master' into jdk-8300645-revert-julong-get-container
>>  - Refactor checked values reading into separate functions
>>  - Merge branch 'master' into jdk-8300645-revert-julong-get-container
>>  - 8300645: Revert julong changes from 8194232 after 8292083
>
> Changes requested by iklam (Reviewer).

@iklam @jdksjolen I've reworked this patch according to your suggestions. It's now only changing the `GET_CONTAINER_INFO` macro which does the logging for the error case with format `%d` unconditionally, therefore fixing the trace log oddity. Please take another look. Thanks!

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

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